# C99 stdint.h

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

1. ### Frederick GothamGuest

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

2. ### Richard HeathfieldGuest

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

3. ### Frederick GothamGuest

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
4. ### Ulrich EckhardtGuest

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
5. ### Schraalhans KeukenmeesterGuest

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
6. ### Tim PrinceGuest

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
7. ### P.J. PlaugerGuest

"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
8. ### Keith ThompsonGuest

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
9. ### Jack KleinGuest

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
10. ### Jack KleinGuest

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
11. ### Chris HillsGuest

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
12. ### Frederick GothamGuest

Chris Hills posted:

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

--

Frederick Gotham

Frederick Gotham, Aug 11, 2006
13. ### Tom St DenisGuest

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
14. ### Flash GordonGuest

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
15. ### 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
16. ### Harald van =?UTF-8?B?RMSzaw==?=Guest

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
17. ### Guest

Harald van DÄ³k 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
18. ### Harald van =?UTF-8?B?RMSzaw==?=Guest

wrote:
>
> Harald van DÄ³k 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."

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
19. ### Guest

Harald van DÄ³k wrote:
> wrote:
> >
> > Harald van DÄ³k 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).

> 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
20. ### Harald van =?UTF-8?B?RMSzaw==?=Guest

wrote:
>
> Harald van DÄ³k wrote:
>> wrote:
>> >
>> > Harald van DÄ³k 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).
>
>> 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