Re: Anyone object to the following change in libc?

From: Erik Trulsson (ertr1013_at_student.uu.se)
Date: 10/31/03

  • Next message: Barney Wolff: "Re: jumbograms (& em) & nfs a no go" 
    Date: Fri, 31 Oct 2003 18:30:07 +0100
To: Garrett Wollman <wollman@khavrinen.lcs.mit.edu>, Bruce Evans <bde@zeta.org.au>, current@freebsd.org

    On Fri, Oct 31, 2003 at 06:20:17PM +0100, Stefan Farfeleder wrote:
    > On Fri, Oct 31, 2003 at 04:43:37PM +0100, Erik Trulsson wrote:
    >
    > > Perhaps not smaller in terms of the sizeof operator, but why can't one
    > > have a 16-bit char, and an int8_t which occupies 16 bits, but only uses
    > > 8 of them - the other 8 being padding?
    >
    > 7.18.1.1 Exact-width integer types
    >
    > 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.

    I see. My confusion stems from the fact that n869.txt (the last
    publically available draft of the C99 standard) says

           7.18.1.1 Exact-width integer types

           [#1] The typedef name intN_t designates a signed integer
           type with width N. Thus, int8_t denotes a signed integer
           type with a width of exactly 8 bits.

    The ", no padding bits" part is apparently one of the things that were changed
    between n869.txt and the final standard.

    Note to self: I really need to get a copy of the final C99 standard as
    soon as I can afford one.

    >
    > > Where in C99 does it say that uint8_t can't have padding bits?
    > > I can't find anything in n869.txt to that effect.
    > > As far as I can tell, the only type that is not allowed to have any
    > > padding bits or trap representations is unsigned char.
    >
    > uint8_t is int8_t's corresponding unsigned type. This means
    > sizeof(uint8_t) == sizeof(int8_t), thus uint8_t can't have padding bits
    > either.

    Yes, with the quote from the standard you supplied above, that becomes
    clear. 

    -- 
<Insert your favourite quote here.>
Erik Trulsson
ertr1013@student.uu.se
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
  • Next message: Barney Wolff: "Re: jumbograms (& em) & nfs a no go"

    Relevant Pages

    • How to find the alignment requirements of a give type in the C99 standard?
      ... "For each of the signed integer types, ... different) unsigned integer type (designated with the keyword ... I can't find any definition of the alignment requirements of ... To comply with the C99 standard, the compiler must ensure b is always ...
      (comp.lang.c)
    • Re: Four or Two Bytes?
      ... Not on the DS9K. ... unsigned short can have INT_MAX padding bytes on the DS9K. ... For unsigned integer types other than unsigned char, ... the bits of the object representation shall be divided into ...
      (comp.lang.c)
    • Re: POSIX and 8-bit bytes
      ... >> N, no padding bits, and a two’s complement representation. ... The section heading "Exact-width integer types" has certain ... >> I don't know of a single hosted implementation for any DSP, ... Porting network stacks is likely, ...
      (comp.lang.c)
    • Re: Differences between pointers
      ... >> rlb@xxxxxxxxxxxxxxxxxxxxxx (Richard Bos) writes: ... >>> must contain padding bits, ... >> sanity.] ... on any other types besides integer types. ...
      (comp.lang.c)
    • Re: Any experience with "The Last One"?
      ... >> Can you please provide the paragraph number for this quote? ... > "For unsigned integer types other than unsigned char, ... > shall be known as the value representation. ...
      (comp.lang.c)