C99 stdint.h

Discussion in 'C Programming' started by Frederick Gotham, Aug 5, 2006.

  1. Here's an excerpt from the Dinkumware library reference:
    __________
    | uint8_t, uint16_t, uint32_t, uint64_t
    |
    | The types each specify an unsigned integer type
    | whose representation has exactly eight, 16, 32,
    | or 64 bits, respectively.
    __________

    How could that be possible if we had a 36-Bit system such as the following?

    char: 9-Bit
    short: 18-Bit
    int: 36-Bit
    long: 36-Bit

    --

    Frederick Gotham
     
    Frederick Gotham, Aug 5, 2006
    #1
    1. Advertising

  2. Frederick Gotham said:

    > Here's an excerpt from the Dinkumware library reference:
    > __________
    > | uint8_t, uint16_t, uint32_t, uint64_t
    > |
    > | The types each specify an unsigned integer type
    > | whose representation has exactly eight, 16, 32,
    > | or 64 bits, respectively.
    > __________
    >
    > How could that be possible if we had a 36-Bit system such as the
    > following?
    >
    > char: 9-Bit
    > short: 18-Bit
    > int: 36-Bit
    > long: 36-Bit


    Well, it couldn't, obviously. And even if it could, would it matter?

    --
    Richard Heathfield
    "Usenet is a strange place" - dmr 29/7/1999
    http://www.cpax.org.uk
    email: rjh at above domain (but drop the www, obviously)
     
    Richard Heathfield, Aug 5, 2006
    #2
    1. Advertising

  3. Richard Heathfield posted:

    > Frederick Gotham said:
    >
    >> Here's an excerpt from the Dinkumware library reference:
    >> __________
    >> | uint8_t, uint16_t, uint32_t, uint64_t
    >> |
    >> | The types each specify an unsigned integer type
    >> | whose representation has exactly eight, 16, 32,
    >> | or 64 bits, respectively.
    >> __________
    >>
    >> How could that be possible if we had a 36-Bit system such as the
    >> following?
    >>
    >> char: 9-Bit
    >> short: 18-Bit
    >> int: 36-Bit
    >> long: 36-Bit

    >
    > Well, it couldn't, obviously. And even if it could, would it matter?



    I would understand if it read:

    Where possible, the types "uint8_t, uint16_t, uint32_t, uint64_t"
    denote an unsigned integer type whose representation has exactly...

    But it doesn't say "where possible" -- it plainly states that these types
    are available... ?

    --

    Frederick Gotham
     
    Frederick Gotham, Aug 5, 2006
    #3
  4. Frederick Gotham wrote:
    > | uint8_t, uint16_t, uint32_t, uint64_t

    [...]
    > How could that be possible if we had a 36-Bit system such as the
    > following?
    >
    > char: 9-Bit
    > short: 18-Bit
    > int: 36-Bit
    > long: 36-Bit


    IIRC, the terms state that those typedefs are present _if_ there are
    suitable types on the system. In the case of a 9 bit byte, they just
    wouldn't be there.

    What you would get would be int_least8_t etc though, I think.

    Uli
     
    Ulrich Eckhardt, Aug 5, 2006
    #4
  5. Frederick Gotham wrote:
    > Here's an excerpt from the Dinkumware library reference:
    > __________
    > | uint8_t, uint16_t, uint32_t, uint64_t
    > |
    > | The types each specify an unsigned integer type
    > | whose representation has exactly eight, 16, 32,
    > | or 64 bits, respectively.
    > __________
    >
    > How could that be possible if we had a 36-Bit system such as the following?
    >
    > char: 9-Bit
    > short: 18-Bit
    > int: 36-Bit
    > long: 36-Bit
    >

    I suppose in order to warrant C99 standard compliance the compiler for
    such a system would have to cater for the necessary translation and
    storage methods. How it does that may not be the programmer's concern,
    as long as he/she sticks to standard C.

    A similar 'problem' exists for 64 bit variables on 32-bit machines. To
    the programmer the long longs are available as if they were a system
    default, yet the compiler translates all relevant code to multiple
    32-bit manipulations.

    Is there a particular (practical) reason for this question??
    Sh.
     
    Schraalhans Keukenmeester, Aug 5, 2006
    #5
  6. Frederick Gotham

    Tim Prince Guest

    Frederick Gotham wrote:
    > Richard Heathfield posted:
    >
    >> Frederick Gotham said:
    >>
    >>> Here's an excerpt from the Dinkumware library reference:
    >>> __________
    >>> | uint8_t, uint16_t, uint32_t, uint64_t
    >>> |
    >>> | The types each specify an unsigned integer type
    >>> | whose representation has exactly eight, 16, 32,
    >>> | or 64 bits, respectively.
    >>> __________
    >>>
    >>> How could that be possible if we had a 36-Bit system such as the
    >>> following?
    >>>
    >>> char: 9-Bit
    >>> short: 18-Bit
    >>> int: 36-Bit
    >>> long: 36-Bit

    >> Well, it couldn't, obviously. And even if it could, would it matter?

    >
    >
    > I would understand if it read:
    >
    > Where possible, the types "uint8_t, uint16_t, uint32_t, uint64_t"
    > denote an unsigned integer type whose representation has exactly...
    >
    > But it doesn't say "where possible" -- it plainly states that these types
    > are available... ?
    >

    Perhaps Dinkumware don't support any 36-bit machines.
     
    Tim Prince, Aug 5, 2006
    #6
  7. Frederick Gotham

    P.J. Plauger Guest

    "Tim Prince" <> wrote in message
    news:...

    > Frederick Gotham wrote:
    >> Richard Heathfield posted:
    >>
    >>> Frederick Gotham said:
    >>>
    >>>> Here's an excerpt from the Dinkumware library reference:
    >>>> __________
    >>>> | uint8_t, uint16_t, uint32_t, uint64_t
    >>>> |
    >>>> | The types each specify an unsigned integer type
    >>>> | whose representation has exactly eight, 16, 32,
    >>>> | or 64 bits, respectively.
    >>>> __________
    >>>>
    >>>> How could that be possible if we had a 36-Bit system such as the
    >>>> following?
    >>>>
    >>>> char: 9-Bit
    >>>> short: 18-Bit
    >>>> int: 36-Bit
    >>>> long: 36-Bit
    >>> Well, it couldn't, obviously. And even if it could, would it matter?

    >>
    >>
    >> I would understand if it read:
    >>
    >> Where possible, the types "uint8_t, uint16_t, uint32_t, uint64_t"
    >> denote an unsigned integer type whose representation has exactly...
    >>
    >> But it doesn't say "where possible" -- it plainly states that these types
    >> are available... ?
    >>

    > Perhaps Dinkumware don't support any 36-bit machines.


    We don't in our prepackaged libraries, to be sure. Our OEM customers
    are free to modify our headers, and documentation, to meet more
    specific needs.

    P.J. Plauger
    Dinkumware, Ltd.
    http://www.dinkumware.com
     
    P.J. Plauger, Aug 5, 2006
    #7
  8. Frederick Gotham <> writes:
    > Here's an excerpt from the Dinkumware library reference:
    > __________
    > | uint8_t, uint16_t, uint32_t, uint64_t
    > |
    > | The types each specify an unsigned integer type
    > | whose representation has exactly eight, 16, 32,
    > | or 64 bits, respectively.
    > __________
    >
    > How could that be possible if we had a 36-Bit system such as the following?
    >
    > char: 9-Bit
    > short: 18-Bit
    > int: 36-Bit
    > long: 36-Bit


    It isn't. The uintN_t types are optional.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
    We must do something. This is something. Therefore, we must do this.
     
    Keith Thompson, Aug 5, 2006
    #8
  9. Frederick Gotham

    Jack Klein Guest

    On Sat, 05 Aug 2006 21:45:52 GMT, Keith Thompson <> wrote
    in comp.lang.c:

    > Frederick Gotham <> writes:
    > > Here's an excerpt from the Dinkumware library reference:
    > > __________
    > > | uint8_t, uint16_t, uint32_t, uint64_t
    > > |
    > > | The types each specify an unsigned integer type
    > > | whose representation has exactly eight, 16, 32,
    > > | or 64 bits, respectively.
    > > __________
    > >
    > > How could that be possible if we had a 36-Bit system such as the following?
    > >
    > > char: 9-Bit
    > > short: 18-Bit
    > > int: 36-Bit
    > > long: 36-Bit

    >
    > It isn't. The uintN_t types are optional.


    Actually, "semi optional" would be more accurate. If an
    implementation provides any or all types which meet the definition,
    namely exactly that many bits, no padding, and 2's complement
    representation for negative values in the signed types, it is required
    to provide the appropriate typedefs.

    --
    Jack Klein
    Home: http://JK-Technology.Com
    FAQs for
    comp.lang.c http://c-faq.com/
    comp.lang.c++ http://www.parashift.com/c -faq-lite/
    alt.comp.lang.learn.c-c++
    http://www.contrib.andrew.cmu.edu/~ajo/docs/FAQ-acllc.html
     
    Jack Klein, Aug 6, 2006
    #9
  10. Frederick Gotham

    Jack Klein Guest

    On Sat, 05 Aug 2006 13:56:08 GMT, Frederick Gotham
    <> wrote in comp.lang.c:

    > Here's an excerpt from the Dinkumware library reference:
    > __________
    > | uint8_t, uint16_t, uint32_t, uint64_t
    > |
    > | The types each specify an unsigned integer type
    > | whose representation has exactly eight, 16, 32,
    > | or 64 bits, respectively.
    > __________
    >
    > How could that be possible if we had a 36-Bit system such as the following?
    >
    > char: 9-Bit
    > short: 18-Bit
    > int: 36-Bit
    > long: 36-Bit


    Purchase and read a copy of the C standard, 1999 or later, and all
    will be revealed to you.

    --
    Jack Klein
    Home: http://JK-Technology.Com
    FAQs for
    comp.lang.c http://c-faq.com/
    comp.lang.c++ http://www.parashift.com/c -faq-lite/
    alt.comp.lang.learn.c-c++
    http://www.contrib.andrew.cmu.edu/~ajo/docs/FAQ-acllc.html
     
    Jack Klein, Aug 6, 2006
    #10
  11. Frederick Gotham

    Chris Hills Guest

    In article <Yr1Bg.12281$>, Frederick Gotham
    <> writes
    >Here's an excerpt from the Dinkumware library reference:
    >__________
    >| uint8_t, uint16_t, uint32_t, uint64_t
    >|
    >| The types each specify an unsigned integer type
    >| whose representation has exactly eight, 16, 32,
    >| or 64 bits, respectively.
    >__________
    >
    >How could that be possible if we had a 36-Bit system such as the following?
    >
    >char: 9-Bit
    >short: 18-Bit
    >int: 36-Bit
    >long: 36-Bit
    >

    Then create and use the following types.

    uint9_t, uint18_t, uint36_t


    --
    \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
    \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
    /\/\/ www.phaedsys.org \/\/\
    \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
     
    Chris Hills, Aug 11, 2006
    #11
  12. Chris Hills posted:

    > Then create and use the following types.
    >
    > uint9_t, uint18_t, uint36_t



    Re-read my question.

    --

    Frederick Gotham
     
    Frederick Gotham, Aug 11, 2006
    #12
  13. Frederick Gotham

    Tom St Denis Guest

    Frederick Gotham wrote:
    > Here's an excerpt from the Dinkumware library reference:
    > __________
    > | uint8_t, uint16_t, uint32_t, uint64_t
    > |
    > | The types each specify an unsigned integer type
    > | whose representation has exactly eight, 16, 32,
    > | or 64 bits, respectively.
    > __________
    >
    > How could that be possible if we had a 36-Bit system such as the following?
    >
    > char: 9-Bit
    > short: 18-Bit
    > int: 36-Bit
    > long: 36-Bit


    The uint types are OPTIONAL. If they exist they are guaranteed to be a
    given size [or at least represent the given range, padding bits
    omitted...].

    This is why using them is dangerous since any C99 conforming compiler
    could not have them.

    Tom
     
    Tom St Denis, Aug 11, 2006
    #13
  14. Frederick Gotham

    Flash Gordon Guest

    Tom St Denis wrote:
    > Frederick Gotham wrote:
    >> Here's an excerpt from the Dinkumware library reference:
    >> __________
    >> | uint8_t, uint16_t, uint32_t, uint64_t
    >> |
    >> | The types each specify an unsigned integer type
    >> | whose representation has exactly eight, 16, 32,
    >> | or 64 bits, respectively.
    >> __________
    >>
    >> How could that be possible if we had a 36-Bit system such as the following?
    >>
    >> char: 9-Bit
    >> short: 18-Bit
    >> int: 36-Bit
    >> long: 36-Bit

    >
    > The uint types are OPTIONAL. If they exist they are guaranteed to be a
    > given size [or at least represent the given range, padding bits
    > omitted...].
    >
    > This is why using them is dangerous since any C99 conforming compiler
    > could not have them.


    Or it is safe because if your code relies on a specific width, and there
    are sometimes good reasons for doing this, then it is guaranteed that it
    won't compile on any system where it would not work.
    --
    Flash Gordon
    Still sigless on this computer.
     
    Flash Gordon, Aug 11, 2006
    #14
  15. Frederick Gotham

    Guest

    Tom St Denis wrote:
    > Frederick Gotham wrote:
    > > Here's an excerpt from the Dinkumware library reference:
    > > __________
    > > | uint8_t, uint16_t, uint32_t, uint64_t
    > > |
    > > | The types each specify an unsigned integer type
    > > | whose representation has exactly eight, 16, 32,
    > > | or 64 bits, respectively.
    > > __________
    > >
    > > How could that be possible if we had a 36-Bit system such as the following?
    > >
    > > char: 9-Bit
    > > short: 18-Bit
    > > int: 36-Bit
    > > long: 36-Bit

    >
    > The uint types are OPTIONAL. If they exist they are guaranteed to be a
    > given size [or at least represent the given range, padding bits
    > omitted...].
    >
    > This is why using them is dangerous since any C99 conforming compiler
    > could not have them.


    Types like uint32_t are required if the implementation
    has a standard integer type that matches it.
     
    , Aug 12, 2006
    #15
  16. wrote:

    >
    > Tom St Denis wrote:
    >> Frederick Gotham wrote:
    >> > Here's an excerpt from the Dinkumware library reference:
    >> > __________
    >> > | uint8_t, uint16_t, uint32_t, uint64_t
    >> > |
    >> > | The types each specify an unsigned integer type
    >> > | whose representation has exactly eight, 16, 32,
    >> > | or 64 bits, respectively.
    >> > __________
    >> >
    >> > How could that be possible if we had a 36-Bit system such as the
    >> > following?
    >> >
    >> > char: 9-Bit
    >> > short: 18-Bit
    >> > int: 36-Bit
    >> > long: 36-Bit

    >>
    >> The uint types are OPTIONAL. If they exist they are guaranteed to be a
    >> given size [or at least represent the given range, padding bits
    >> omitted...].
    >>
    >> This is why using them is dangerous since any C99 conforming compiler
    >> could not have them.

    >
    > Types like uint32_t are required if the implementation
    > has a standard integer type that matches it.


    Two nits: uint32_t is required if the implementation has an integer type
    (standard integer type or extended integer type) that matches it, and the
    implementation also has an integer type that matches int32_t.
     
    Harald van =?UTF-8?B?RMSzaw==?=, Aug 13, 2006
    #16
  17. Frederick Gotham

    Guest

    Harald van Dijk wrote:
    > wrote:
    >
    > >
    > > Tom St Denis wrote:
    > >> Frederick Gotham wrote:
    > >> > Here's an excerpt from the Dinkumware library reference:
    > >> > __________
    > >> > | uint8_t, uint16_t, uint32_t, uint64_t
    > >> > |
    > >> > | The types each specify an unsigned integer type
    > >> > | whose representation has exactly eight, 16, 32,
    > >> > | or 64 bits, respectively.
    > >> > __________
    > >> >
    > >> > How could that be possible if we had a 36-Bit system such as the
    > >> > following?
    > >> >
    > >> > char: 9-Bit
    > >> > short: 18-Bit
    > >> > int: 36-Bit
    > >> > long: 36-Bit
    > >>
    > >> The uint types are OPTIONAL. If they exist they are guaranteed to be a
    > >> given size [or at least represent the given range, padding bits
    > >> omitted...].
    > >>
    > >> This is why using them is dangerous since any C99 conforming compiler
    > >> could not have them.

    > >
    > > Types like uint32_t are required if the implementation
    > > has a standard integer type that matches it.

    >
    > Two nits: uint32_t is required if the implementation has an integer type
    > (standard integer type or extended integer type) that matches it,


    Yes. Notice I spelled if with only one f.

    > and the
    > implementation also has an integer type that matches int32_t.


    That's not how I read the requirement. An int32_t must
    be provided if there's a type that matches it; a uint32_t
    must be provided if there's a type that matches it; but
    either can be required without the existence of the other.
     
    , Aug 13, 2006
    #17
  18. wrote:
    >
    > Harald van Dijk wrote:
    >> wrote:
    >>
    >> >
    >> > Tom St Denis wrote:
    >> >> Frederick Gotham wrote:
    >> >> > Here's an excerpt from the Dinkumware library reference:
    >> >> > __________
    >> >> > | uint8_t, uint16_t, uint32_t, uint64_t
    >> >> > |
    >> >> > | The types each specify an unsigned integer type
    >> >> > | whose representation has exactly eight, 16, 32,
    >> >> > | or 64 bits, respectively.
    >> >> > __________
    >> >> >
    >> >> > How could that be possible if we had a 36-Bit system such as the
    >> >> > following?
    >> >> >
    >> >> > char: 9-Bit
    >> >> > short: 18-Bit
    >> >> > int: 36-Bit
    >> >> > long: 36-Bit
    >> >>
    >> >> The uint types are OPTIONAL. If they exist they are guaranteed to be
    >> >> a given size [or at least represent the given range, padding bits
    >> >> omitted...].
    >> >>
    >> >> This is why using them is dangerous since any C99 conforming compiler
    >> >> could not have them.
    >> >
    >> > Types like uint32_t are required if the implementation
    >> > has a standard integer type that matches it.

    >>
    >> Two nits: uint32_t is required if the implementation has an integer type
    >> (standard integer type or extended integer type) that matches it,

    >
    > Yes. Notice I spelled if with only one f.
    >
    >> and the
    >> implementation also has an integer type that matches int32_t.

    >
    > That's not how I read the requirement. An int32_t must
    > be provided if there's a type that matches it; a uint32_t
    > must be provided if there's a type that matches it; but
    > either can be required without the existence of the other.


    7.18.1p1:
    "When typedef names differing only in the absence or presence of the initial
    u are deï¬ned, they shall denote corresponding signed and unsigned types as
    described in 6.2.5; an implementation providing one of these corresponding
    types shall also provide the other."

    I'll admit 7.18.1.1p3 is ambiguous, but your (unfortunately legitimate)
    interpretation of it leads to ridiculous results, such as any
    implementation with CHAR_BIT==8 and no two's complement being
    nonconforming.
     
    Harald van =?UTF-8?B?RMSzaw==?=, Aug 13, 2006
    #18
  19. Frederick Gotham

    Guest

    Harald van Dijk wrote:
    > wrote:
    > >
    > > Harald van Dijk wrote:
    > >> wrote:
    > >>
    > >> >
    > >> > Tom St Denis wrote:
    > >> >> Frederick Gotham wrote:
    > >> >> > Here's an excerpt from the Dinkumware library reference:
    > >> >> > __________
    > >> >> > | uint8_t, uint16_t, uint32_t, uint64_t
    > >> >> > |
    > >> >> > | The types each specify an unsigned integer type
    > >> >> > | whose representation has exactly eight, 16, 32,
    > >> >> > | or 64 bits, respectively.
    > >> >> > __________
    > >> >> >
    > >> >> > How could that be possible if we had a 36-Bit system such as the
    > >> >> > following?
    > >> >> >
    > >> >> > char: 9-Bit
    > >> >> > short: 18-Bit
    > >> >> > int: 36-Bit
    > >> >> > long: 36-Bit
    > >> >>
    > >> >> The uint types are OPTIONAL. If they exist they are guaranteed to be
    > >> >> a given size [or at least represent the given range, padding bits
    > >> >> omitted...].
    > >> >>
    > >> >> This is why using them is dangerous since any C99 conforming compiler
    > >> >> could not have them.
    > >> >
    > >> > Types like uint32_t are required if the implementation
    > >> > has a standard integer type that matches it.
    > >>
    > >> Two nits: uint32_t is required if the implementation has an integer type
    > >> (standard integer type or extended integer type) that matches it,

    > >
    > > Yes. Notice I spelled if with only one f.
    > >
    > >> and the
    > >> implementation also has an integer type that matches int32_t.

    > >
    > > That's not how I read the requirement. An int32_t must
    > > be provided if there's a type that matches it; a uint32_t
    > > must be provided if there's a type that matches it; but
    > > either can be required without the existence of the other.

    >
    > 7.18.1p1:
    > "When typedef names differing only in the absence or presence of the initial
    > u are defined, they shall denote corresponding signed and unsigned types as
    > described in 6.2.5; an implementation providing one of these corresponding
    > types shall also provide the other."


    Interesting. This can be read either as saying that
    an implementation can't provide uint32_t unless it
    also provides int32_t (and vice versa), or as saying
    that if an implementation has a type that matches
    uint32_t it must also provide a type that matches
    int32_t (and vice versa) (and similarly for 8,16,64).

    > I'll admit 7.18.1.1p3 is ambiguous, but your (unfortunately legitimate)
    > interpretation of it leads to ridiculous results, such as any
    > implementation with CHAR_BIT==8 and no two's complement being
    > nonconforming.


    An implementation with CHAR_BIT==8 and ones complement
    for signed char would simply be required to have an
    extended integer type with size 1 and that uses twos
    complement for its signed type. There's no reason an
    implementation can't have both ones complement types
    and twos complement types.

    In any case, good to have 7.18.1p3 pointed out.
     
    , Aug 13, 2006
    #19
  20. wrote:
    >
    > Harald van Dijk wrote:
    >> wrote:
    >> >
    >> > Harald van Dijk wrote:
    >> >> wrote:
    >> >>
    >> >> >
    >> >> > Tom St Denis wrote:
    >> >> >> Frederick Gotham wrote:
    >> >> >> > Here's an excerpt from the Dinkumware library reference:
    >> >> >> > __________
    >> >> >> > | uint8_t, uint16_t, uint32_t, uint64_t
    >> >> >> > |
    >> >> >> > | The types each specify an unsigned integer type
    >> >> >> > | whose representation has exactly eight, 16, 32,
    >> >> >> > | or 64 bits, respectively.
    >> >> >> > __________
    >> >> >> >
    >> >> >> > How could that be possible if we had a 36-Bit system such as the
    >> >> >> > following?
    >> >> >> >
    >> >> >> > char: 9-Bit
    >> >> >> > short: 18-Bit
    >> >> >> > int: 36-Bit
    >> >> >> > long: 36-Bit
    >> >> >>
    >> >> >> The uint types are OPTIONAL. If they exist they are guaranteed to
    >> >> >> be a given size [or at least represent the given range, padding
    >> >> >> bits omitted...].
    >> >> >>
    >> >> >> This is why using them is dangerous since any C99 conforming
    >> >> >> compiler could not have them.
    >> >> >
    >> >> > Types like uint32_t are required if the implementation
    >> >> > has a standard integer type that matches it.
    >> >>
    >> >> Two nits: uint32_t is required if the implementation has an integer
    >> >> type (standard integer type or extended integer type) that matches it,
    >> >
    >> > Yes. Notice I spelled if with only one f.
    >> >
    >> >> and the
    >> >> implementation also has an integer type that matches int32_t.
    >> >
    >> > That's not how I read the requirement. An int32_t must
    >> > be provided if there's a type that matches it; a uint32_t
    >> > must be provided if there's a type that matches it; but
    >> > either can be required without the existence of the other.

    >>
    >> 7.18.1p1:
    >> "When typedef names differing only in the absence or presence of the
    >> initial u are defined, they shall denote corresponding signed and
    >> unsigned types as described in 6.2.5; an implementation providing one of
    >> these corresponding types shall also provide the other."

    >
    > Interesting. This can be read either as saying that
    > an implementation can't provide uint32_t unless it
    > also provides int32_t (and vice versa), or as saying
    > that if an implementation has a type that matches
    > uint32_t it must also provide a type that matches
    > int32_t (and vice versa) (and similarly for 8,16,64).
    >
    >> I'll admit 7.18.1.1p3 is ambiguous, but your (unfortunately legitimate)
    >> interpretation of it leads to ridiculous results, such as any
    >> implementation with CHAR_BIT==8 and no two's complement being
    >> nonconforming.

    >
    > An implementation with CHAR_BIT==8 and ones complement
    > for signed char would simply be required to have an
    > extended integer type with size 1 and that uses twos
    > complement for its signed type.


    Meaning if it has no such two's complement type, it cannot be conforming.
    That's what I said, isn't it?

    > There's no reason an
    > implementation can't have both ones complement types
    > and twos complement types.


    The standard doesn't prohibit it, but hardware limitations are a possible
    reason.

    > In any case, good to have 7.18.1p3 pointed out.


    I'm not sure if you mean 7.18.1p1 or 7.18.1.1p3, but either way :)
     
    Harald van =?UTF-8?B?RMSzaw==?=, Aug 13, 2006
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. J. Campbell
    Replies:
    6
    Views:
    688
    Frank Schmitt
    Jan 19, 2004
  2. making literals be a stdint size

    , Aug 25, 2003, in forum: C Programming
    Replies:
    8
    Views:
    369
  3. Scott David Daniels

    What GCC version had <stdint.h> defined?

    Scott David Daniels, Aug 26, 2004, in forum: Python
    Replies:
    10
    Views:
    5,612
    Scott David Daniels
    Aug 31, 2004
  4. Replies:
    3
    Views:
    3,683
    Chris Torek
    Feb 20, 2006
  5. Replies:
    3
    Views:
    603
    Keith Thompson
    Mar 31, 2007
Loading...

Share This Page