linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Bill Rugolsky Jr." <brugolsky@telemetry-investments.com>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: blp@cs.stanford.edu, linux-kernel@vger.kernel.org
Subject: extended integer types (was Re: [patch] Input cleanups for 2.5.29 [2/2])
Date: Wed, 31 Jul 2002 10:01:07 -0400	[thread overview]
Message-ID: <20020731100107.A14404@ti18> (raw)
In-Reply-To: <1028122978.8510.59.camel@irongate.swansea.linux.org.uk>; from alan@lxorguk.ukuu.org.uk on Wed, Jul 31, 2002 at 02:42:58PM +0100

On Wed, Jul 31, 2002 at 02:42:58PM +0100, Alan Cox wrote:
> On Tue, 2002-07-30 at 22:55, Ben Pfaff wrote:
> > 1    The typedef name intN_t designates a signed integer type with
> >      width N, no padding bits, and a two's complement
> >      representation. Thus, int8_t denotes a signed integer type
> >      with a width of exactly 8 bits.
> 
> And arbitary alignment requirements. At least I see nothing in C99
> saying that
> 
> 	uint8_t foo;
> 	uint8_t bar;
> 
> isnt allowed to give you interesting suprises

The problem here is footnote 215, which says "Some of these types may
denote implementation-defined extended integer types."  The rest of
section 7.18 is built around a conceptual model of the extended integer
types as aliases to the standard types.

The standard almost surely means the smallest such type, but does
not in fact say that.  The standards language appears to conflate the
value semantics with the representation width.  (However, see the
description of int_leastN.) I will consider filing a defect report.

The C99 <stdint.h> types are the bastard child of a paper by Frank
Farance and myself on extended integer type semantics, combined with an
earlier [u]intN_t proposal.  Our input to the C9x process largely ended
with the discussion of the original paper, for unrelated reasons.

The intention was to remove the ambiguity in much legacy code that used
"long" in two ways: as the largest integral type, and as an exact 32-bit
container.  IIRC, the original proposal described integral types with the
following semantics:

   exact<n>

      exact [un]signed n-bit arithmetic in the smallest supported
      integral container, so that if a standard type of width <n> bits
      exists, then exact<n> corresponds to it.  Hence sizeof(exact<8>)
      == 1 on all sane platforms.  Think bitfields in auto-sized
      containers.

   least<n> -

      [un]signed arithmetic with the smallest integral type >= n bits
      that is "natural" to the platform, typically half-register,
      register, or double-register width.  least<n> corresponds to exact<m>
      for some m >= n.

   fast<n>

      the fastest "natural" (i.e., [half-]register)  width for the platform,
      to be used for accumulators, etc., where external representation
      is unimportant.

Humbly,

    Bill Rugolsky


  parent reply	other threads:[~2002-07-31 13:57 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-07-30 10:26 [patch] Small input fixes for 2.5.29 [1/2] Vojtech Pavlik
2002-07-30 10:29 ` [patch] Small input fixes for 2.5.29 [2/2] Vojtech Pavlik
2002-07-30 13:22   ` [patch] Input cleanups for 2.5.29 [1/2] Vojtech Pavlik
2002-07-30 13:23     ` [patch] Input cleanups for 2.5.29 [2/2] Vojtech Pavlik
2002-07-30 20:17       ` [patch] Fix suspend of the kseriod thread Vojtech Pavlik
2002-07-30 20:18         ` [patch] Remove superfluous code that snuck back in PPC merge Vojtech Pavlik
2002-07-30 21:57         ` [patch] Fix suspend of the kseriod thread Russell King
2002-07-30 22:00           ` Vojtech Pavlik
2002-07-31  9:55         ` David Woodhouse
2002-07-31  9:58           ` Vojtech Pavlik
2002-07-31 10:07           ` David Woodhouse
2002-07-31 10:10             ` Vojtech Pavlik
2002-07-31 11:44             ` sleep_on() DIE DIE DIE (was Re: [patch] Fix suspend of the kseriod thread) David Woodhouse
2002-07-30 21:09       ` [patch] Input cleanups for 2.5.29 [2/2] Greg KH
2002-07-30 21:20         ` Linus Torvalds
2002-07-30 21:35           ` Vojtech Pavlik
2002-07-30 21:46             ` Linus Torvalds
2002-07-30 22:02               ` Vojtech Pavlik
2002-07-30 21:38           ` Brad Hards
2002-07-30 21:26         ` Brad Hards
2002-07-30 21:35           ` Linus Torvalds
2002-07-30 21:42             ` Alexander Viro
2002-07-30 21:47               ` Brad Hards
2002-07-30 22:02                 ` Alexander Viro
2002-07-30 22:05                   ` Alexander Viro
2002-08-01 10:49                     ` Pavel Machek
2002-08-01 12:17                       ` Sean Neakums
2002-07-30 22:04                 ` Linus Torvalds
2002-07-30 21:55               ` Ben Pfaff
2002-07-30 22:03                 ` Alexander Viro
2002-07-31 13:42                 ` Alan Cox
2002-07-31 12:57                   ` Andreas Schwab
2002-07-31 14:01                   ` Bill Rugolsky Jr. [this message]
2002-07-30 21:39           ` Vojtech Pavlik
2002-07-30 22:46             ` Kai Henningsen
2002-07-30 21:45         ` Jeff Garzik
2002-07-30 21:59           ` Linus Torvalds

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20020731100107.A14404@ti18 \
    --to=brugolsky@telemetry-investments.com \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=blp@cs.stanford.edu \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).