Sizes of Integer Types

[Kelsey Bjarnason]

Now you're portable across implementations that support those types.

What types? The new int types which aren't required to even exist? Yes,
indeed. Portability goes straight down the crapper.

 

[Kelsey Bjarnason]

[snips]

If your application requires fixed width types, your application
requires fixed with types. Why should giving them a standardised name
make you code less portable? The fixed width requirement has already
restricted its portability.

Much code _could benefit from_ fixed width types, even if it does not
strictly _need_ them. I happen to write code which falls into this
category.

Thanks to the new int types, I have a wonderful new world in which my code
can be simpler and more efficient in the general case, while possibly
relying on slower emulated types in the oddball case, but trading that off
against reduced code complexity and reduced memory overhead.

This would be a *wonderful* set of affairs, and the new int types make it
all happen - 8 bit integer types, 16 bit integer types, 32 bit integer
types, life is good.

Except it ain't, because when the code compiles on implementation X, the
very types which make life so much better _do not exist_.

Two choices:

1) Simply suck it up and accept that _C_ code will no long work on
anything but the restricted set of machines providing the exact set of
integer types you want (so much for portability)

2) Write the program so it doesn't rely on things which aren't going to
exist (so much for int types)

Since there is very little justification, particularly in most of the code
I write, to limit its migration from system to system, restricting the
code to a comparative hatful of systems is silly. Thus my only option is
to skip the int types.

This forces me to ask the reason they exist. Someone has opined it is for
those cases - few though they may be - where you're working on a
restricted set of implementations, writing something like, oh, device
drivers, where having a 32-bit type would be a boon.

Well, yes, I agree; in those cases, having a 32-bit type would be a boon.
Further, on those systems, we know _a_ type must be 32 bits, or the new
int types wouldn't work, and guess what? People have been writing just
this sort of code on just that sort of system for decades, without the use
of the new int types.

These things _could_ have been made appealing, _could_ have been made
reliable, _could_ have been made actually useful. Instead they were
dropped in in a manner which renders them, in every case I've seen
discussed thus far, either completely valueless or at best of the trivial
value of saving the developer writing a typedef.

Neither of those are sufficient justification, IMO, for including such a
half-baked notion to be enshrined in the standard, yet there they are. So
again, I ask, *what use are they*?

So far, not one good answer to that has come forth.

 

[jacob navia]

[snips]

Do you REALLY find so hard to understand that some code does not have to
be portable to every system?

Do you REALLY find it so hard to understand that if you're writing code
where you _know_ the sizes involved on the implementation, you don't
_need_ the uint16_t crap in the first place, as people have been writing
this sort of code for 30 years and more without the new types?

I have a lot of code and there is a lot of code in public domain
software like GTK for instance, where the developer defined
precisely uint16 and uint32 and all those types. They have a
need for it, and the C99 standard defined those types to make
a standard and portable definition for them. In most system that exist
now they will be there, but the standard did not force them to exist
in the case some weird acrchitecture in the futurez does not implement
them.


Your continuous ignorance of this simple fact means that you are
unable to understand that and further discussion with you
is worthless. I have not participated in this thread precisely
because of this, and this will be my last post.

 

[Kelsey Bjarnason]

[snips]

Ok, show me how to write a typedef for a signed type that's exactly 32
bits wide, with no padding bits and a 2's-complement representation,
so that I don't have to change the definition for different platforms.

Oh, wait, somebody's already done that for you; it's called uint32_t.

Good. Show me where this is defined on a machine with 64-bit types.
Whoops. Doesn't exist. Next.

Show me where anybody claimed that it's defined on a machine with
64-bit types.

So we're agreed: if you rely on the new int types, you can toss portability
right out the freakin' window, and on the flip side, the "benefit" to
these types is... to avoid writing a typedef.

A language feature of such limited apparent value that it causes this
much discussion is probably a dubious item at best, and when the only
benefit that's been offered thus far is to not have to create your own
typedef, the benefits just do not seem sufficient for this feature to
exist at all.

Meanwhile the downsides are pretty obvious: use the feature, forget
portability, avoid the feature and we just end up with another "auto" or
"gets" - unwanted dross laying about cluttering things up.

 

[Bart van Ingen Schenau]

[snips]

Then please show us your typedef for a type of *exactly* 32 bits on a
system with 9-bit char, 18-bit short, 36-bit int and long and 72-bit
long long.

And your uint32_t exists on a machine with 64-bit types, right?

Nope. Next.

*PLONK*

 

[lawrence.jones]

It looks like a draft of what will someday be
the corrected version of C99.

Kind of. The TCs formally amend the Standard. The powers-that-be are
entitled to ask the technical committee at any time to provide a revised
copy of the Standard for publication instead of and/or in addition to a
TC document. N1124 is a draft of what that revised copy might look
like, should it be requested. That document would be a new (third)
edition of the standard that cancels and replaces the current second
edition (C99) and thus would have a new designation (e.g., C07).

If that's what it is,
then I think that everybody who bought a C99 standard,
is entitled to the corrected version.

The formal TC documents are generally available electronically at no
charge. You don't get the next edition of the Standard for free any
more than you get subsequent editions of any other book for free. (But
you *do* get the drafts for free!)

This might be a good place to note that N1256, an updated draft
incorporating the new TC3, has just been published:

<http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf>

-Larry Jones

Isn't it sad how some people's grip on their lives is so precarious
that they'll embrace any preposterous delusion rather than face an
occasional bleak truth? -- Calvin

 

[Al Balmer]

[snips]

On Thu, 06 Sep 2007 11:51:57 -0700, Keith Thompson wrote:

If you just want integer types of specified sizes, take a look at the
<stdint.h> header, which defines int8_t, int16_t, etc.

My copy of the draft says that intN_t types are optional, an
implementation is not required to provide them. As such, it strikes me
that code cannot rely on them unless one gives up portability across
compilers, never mind OSen.

Has this changed, or is this still little more than a good way to
guarantee you're stuck using one vendor's compiler for the rest of
eternity?

int8_t, int16_t, int32_t, int64_t and the corresponding unsigned integer
types are required on systems where there exist types matching the
descriptions. This means that on C99 implementations where they're not
defined, it wouldn't be possible to use some other type as a substitute
anyway, unless you didn't really need an exact-width integer type in the
first place.

It would have been good to mandate their support on _all_ architectures.
Odd bit sized and non 2's complement machines could emulate them in
software...

For purposes of calculation they could. Probably even for purposes of
satisfying the standard. But there might be times when you actually
need the hardware to be able to write say 16 bits and no more, such as
for writing to a 16-bit memory mapped port, where the adjacent 16 bits
is a different port.

Such biests are disappearing fast at this time,

They are?

 

[Al Balmer]

"Harald van D?k" <[email protected]> a écrit dans le message de [email protected]... [...]
int8_t, int16_t, int32_t, int64_t and the corresponding unsigned integer
types are required on systems where there exist types matching the
descriptions. This means that on C99 implementations where they're not
defined, it wouldn't be possible to use some other type as a substitute
anyway, unless you didn't really need an exact-width integer type in the
first place.

It would have been good to mandate their support on _all_ architectures.
Odd bit sized and non 2's complement machines could emulate them in
software...
Such biests are disappearing fast at this time, and lack of complete c99
support for them would not have hurt anybody.

Definitely something to remember for the next release.

How would you emulate uint8_t (which, remember, must have no padding
bits) on an implementation with CHAR_BIT==9, which therefore cannot
support 8-bit objects?

You do not emulate its representation, but you can emulate its well defined
arithmetic behaviour with available hardware operations and appropriate
masks, shifts, etc. The compiler is already doing something very similar
for bitfields.

Arithmetic isn't everything.

 

[Al Balmer]

What types? The new int types which aren't required to even exist? Yes,
indeed. Portability goes straight down the crapper.

You keep saying that. The new types *are* required to exist, if the
implementation can support them. You've been quoted C&V.

If the implementation *can't* support the type you need, all the
#ifdef's in the world won't help.

 

[Al Balmer]

[snips]
On Wed, 12 Sep 2007 11:34:45 -0700, Keith Thompson wrote:
Ok, show me how to write a typedef for a signed type that's exactly 32
bits wide, with no padding bits and a 2's-complement representation,
so that I don't have to change the definition for different platforms.

Oh, wait, somebody's already done that for you; it's called uint32_t.

Good. Show me where this is defined on a machine with 64-bit types.
Whoops. Doesn't exist. Next.

Show me where anybody claimed that it's defined on a machine with
64-bit types.

So we're agreed: if you rely on the new int types, you can toss portability
right out the freakin' window, and on the flip side, the "benefit" to
these types is... to avoid writing a typedef.

If writing a typedef will do the job, then so will the new int type.
The difference is that the new int type will work on *all*
implementations which have *any* suitable type, without needing
conditional compilation, whereas you will have to write different
typedef's for different architectures, and some poor maintainer will
have to figure it out.

 

[Kelsey Bjarnason]

[snips]

You keep saying that. The new types *are* required to exist

Really? So uint8_t exists on a machine with 64-bit char and short and int
and long? No, it doesn't. Continuing...

, if the
implementation can support them.

"If". And if it doesn't, they don't exist.

Exactly my point. So we're all agreed. Good.

So I now have new int types which, as I keep - correctly - stating aren't
required to exist, so that using them means portability goes straight down
the crapper.

We *are* all in agreement on this, right?

 

[Keith Thompson]

This might be a good place to note that N1256, an updated draft
incorporating the new TC3, has just been published:

<http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf>

Cool, thanks!

Is TC3 itself available? (I got TC1 and TC2 as free downloads from
webstore.ansi.org, but TC3 isn't there yet.)

 

[Kelsey Bjarnason]

[snips]

If writing a typedef will do the job, then so will the new int type.

Making the new int type at best a convenience.

The difference is that the new int type will work on *all*
implementations which have *any* suitable type

Rather than "on all implementations", where, oh, int and char will
continue to work.

Again, exactly my point. What _could have been_ a wonderfully useful
notion has instead become little more than a way to limit the portability
of the code.

 

[Keith Thompson]

"Harald van D?k" <[email protected]> a écrit dans le message de [email protected]... [...]
int8_t, int16_t, int32_t, int64_t and the corresponding unsigned integer
types are required on systems where there exist types matching the
descriptions. This means that on C99 implementations where they're not
defined, it wouldn't be possible to use some other type as a substitute
anyway, unless you didn't really need an exact-width integer type in the
first place.

It would have been good to mandate their support on _all_ architectures.
Odd bit sized and non 2's complement machines could emulate them in
software...
Such biests are disappearing fast at this time, and lack of complete c99
support for them would not have hurt anybody.

Definitely something to remember for the next release.

How would you emulate uint8_t (which, remember, must have no padding
bits) on an implementation with CHAR_BIT==9, which therefore cannot
support 8-bit objects?

You do not emulate its representation, but you can emulate its well defined
arithmetic behaviour with available hardware operations and appropriate
masks, shifts, etc. The compiler is already doing something very similar
for bitfields.

And what if I want to write exactly 8 bits to a binary file?

 

[Flash Gordon]

Philip Potter wrote, On 13/09/07 09:15:

I don't normally make one-line replies but: Hear hear.

I have not been following who thinks what as carefully as I might. If
Richard and you agree than limiting portability by using fixed width
type _where_appropriate_ then I obviously have no argument with you on this.

For what it is worth, I'm going to be converting some more code to use
it because the library in question will be writing the data (or reading
it) to else-where where (sometimes physical files) there is for good
reasons a requirement that the stored value is *exactly* a specific
width. There is already code to deal with endianness, and we would have
major work for other reasons if we ported to other than Windows/*nix, so
this is appropriate. I will convert other parts to use the "fast" types
because I know the source data is no more than a given number of bits,
and at those points speed is the most important thing.

 

[Keith Thompson]

The paragraph in the draft you are looking at may be identical to the
one in the ratified standard BUT other paragraphs in the standard, but
not in the draft, may alter the use of the one paragraph you have
quoted.

In high integrity, safety critical or other controlled development
environments (IS) 9K, CMM etc using an uncontrolled document ie a
draft can get you sacked. And rightly so.


A Draft is just that. I know personally from working on these
standards that many things can change between draft (eve final draft)
and publication. If you use a Draft when there is a published standard
then you don't have a leg to stand on.

Just because the one paragraph is the same it don't mean a
thing. Especially when the other paragraph in the publish standard,
but not in the draft, does have a bearing on the paragraph you are
quoting... but you knew that didn't you?

Once again, let's be clear about which draft we're talking about.
I've been using N1124, which incorporates the C99 standard as modified
by TC1 and TC2. As I understand it, the Technical Corrigenda have as
much authority as the standard itself (please correct me if I'm
mistaken on this point). The *official* authority, I suppose, is C99
plus TC1 and TC2 as separate documents (I have copies of those too),
but N1124 is a lot more convenient.

If you're talking about N869, which was a pre-C99 working draft, then
I mostly agree with you, though I'm not as concerned about it as you
are.

Next time I'm working in a high integrity, safety critical or other
controlled development environment, I'll be sure to use the standard
(or whatever document I'm required to use). In the unlikely event
that I ever testify in a court of law about what the C standard says,
I'll refer to the official C standard. (Though as far as I know the C
standard doesn't have the force of law unless some other law or
contract refers to it -- and such a law or contract *could*
conceivably refer instead to n1124.)

This is a newsgroup. It's a bunch of people having a discussion. No
official authority is necesary. We routinely quote from the C90
standard (which is "officially" obsolete), and from K&R2, which has no
official standing at all. We even quote each other, and we think up
stuff as we're writing it, as I'm doing now.

Larry Jones just announced that a new draft is available at

<http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf>

incorporating C99, TC1, TC2, and TC3. I intend to start using that as
my primary reference, going back to the "official" C99 standard only
when necessary. (If something in C99 has been modified by one of the
Technical Corrigenda, I want to know about it.)

 

[jacob navia]

[snips]

You keep saying that. The new types *are* required to exist

Really? So uint8_t exists on a machine with 64-bit char and short and int
and long? No, it doesn't. Continuing...

, if the
implementation can support them.

"If". And if it doesn't, they don't exist.

Exactly my point. So we're all agreed. Good.

So I now have new int types which, as I keep - correctly - stating aren't
required to exist, so that using them means portability goes straight down
the crapper.

We *are* all in agreement on this, right?

If the types do not exist, it means the machine can't do any operation
with those types!

With YOUR alternative, you are in the same position. Even if you
invent some typedef for 8 bit ints, if the machine can't DO THAT
this is wrong and must be programmed around with masks!!!!

This means that the NON EXISTENCE of those types allows you
to catch that error at COMPILE TIME!!!

But you go on and on saying nonsense. Incredible!

 

[Flash Gordon]

Kelsey Bjarnason wrote, On 13/09/07 17:10:

[snips]

Do you REALLY find so hard to understand that some code does not have to
be portable to every system?

Do you REALLY find it so hard to understand that if you're writing code
where you _know_ the sizes involved on the implementation, you don't
_need_ the uint16_t crap in the first place, as people have been writing
this sort of code for 30 years and more without the new types?

Ah, but I don't know in advance *which* of the base types will actually
be the required size, only that there will be one. The C99 standard
saves me from having to write that code. Just as the first assembler
saved people from having to write machine code and the first
higher-level language saved people from having to write assembler. It is
exactly the same thing, saving the developer from having to do some of
the work by putting it on the implementer.

Do you REALLY find it so hard to understand that these types offer no real
benefit in this case, and _cannot_ be relied on in pretty much any other
case, rendering them completely worthless?

You fail to understand that the CAN be relied on to exist in ALL
implementations of interest. However, on SOME of those implementations
the appropriate type would be unsigned char, on others unsigned short,
on others unsigned int. The value is that I don't ahve to worry about
*which* type meets the requirements.

Just because something has no worth to you does NOT mean it has no worth
to others.

You have also yet to answer my question. Will ALL of your code run on
the systems I have used with only 8K of program space, 8K of data space,
and 16 bit char, short and int with a 32 bit long? Are ALL of you
programs small enough to fit? If not, YOU have thrown portability right
out the window, so why are you complaining that others don't want
portability to everything?

If you don't answer this time I will assume that by portability you mean
"portability ONLY to implementations approved by Kelsey Bjarnason" in
which case everything you are saying is completely irrelevant to
everyone else.

 

[Flash Gordon]

Kelsey Bjarnason wrote, On 13/09/07 17:47:

[snips]
On Wed, 12 Sep 2007 11:34:45 -0700, Keith Thompson wrote:
Ok, show me how to write a typedef for a signed type that's exactly 32
bits wide, with no padding bits and a 2's-complement representation,
so that I don't have to change the definition for different platforms.

Oh, wait, somebody's already done that for you; it's called uint32_t.
Good. Show me where this is defined on a machine with 64-bit types.
Whoops. Doesn't exist. Next.

Show me where anybody claimed that it's defined on a machine with
64-bit types.

So we're agreed: if you rely on the new int types, you can toss portability
right out the freakin' window,

NO WE ARE NOT! You are limiting portability, just as you are when you
write a program that uses more than a certain minimal amount of memory,
or when you use networking, or when you use any one of a number of other
things!

and on the flip side, the "benefit" to
these types is... to avoid writing a typedef.

No, to avoid having to write and VERIFY a hole mess of conditional code
to select the correct type INCLUDING on implementations you don't
currently have and INCLUDING verifying that it will correctly fail to
compile on other implementations you don't have.

A language feature of such limited apparent value that it causes this
much discussion is probably a dubious item at best, and when the only
benefit that's been offered thus far is to not have to create your own
typedef, the benefits just do not seem sufficient for this feature to
exist at all.

So anything not useful to you personally is of insufficient benefit to
be worth including. In that case just write your own language with
exactly what you want.

Meanwhile the downsides are pretty obvious: use the feature, forget
portability,

Portability is not a binary concept.

avoid the feature and we just end up with another "auto"

I can see why auto was potentially useful and so in the language at one
point.

or
"gets"

A completely different matter.

- unwanted dross laying about cluttering things up.

Unwanted by *you* does not mean unwanted. In case you have not noticed
from the number of people who do want it, IT IS WANTED. What you want
and find useful does NOT define what others want or find useful.

 

[Keith Thompson]

[snips]
On Wed, 12 Sep 2007 11:34:45 -0700, Keith Thompson wrote:
Ok, show me how to write a typedef for a signed type that's exactly 32
bits wide, with no padding bits and a 2's-complement representation,
so that I don't have to change the definition for different platforms.

Oh, wait, somebody's already done that for you; it's called uint32_t.

Good. Show me where this is defined on a machine with 64-bit types.
Whoops. Doesn't exist. Next.

Show me where anybody claimed that it's defined on a machine with
64-bit types.

So we're agreed: if you rely on the new int types, you can toss portability
right out the freakin' window, and on the flip side, the "benefit" to
these types is... to avoid writing a typedef.

No, we are not agreed. Portability is not a black-and-white thing.
Sometimes portability to a subset of all possible implementations is
good enough.

Writing a typedef for an unsigned type that's exactly 32 bits wide
with no padding bits isn't terribly difficult, but it's not trivial.
Writing a similar typedef for a signed type is probably a little
harder. In fact, Doug Gwyn wrote a C90-compatible version of
<stdint.h> as part of his "q8" package.

Yes the benefit is avoiding writing a typedef. Actually, it's
avoiding *everyone* writing their own typedefs, with different names
and subtly different meanings -- see "WORD", "u32", "uint32", etc.

You suggest that it would have been better to require all these types
to be supported for all implementations, even if they have to be
emulated. That would have required substantial extra work for
implementers. It might not even be possible to emulate all the
required attributes on some systems; consider a 32-bit type with no
padding bits on a system with CHAR_BIT==9. Requiring them to exist
only where the underlying types already exist was a compromise; in my
opinin, it was a perfectly reasonable one.

A language feature of such limited apparent value that it causes this
much discussion is probably a dubious item at best, and when the only
benefit that's been offered thus far is to not have to create your own
typedef, the benefits just do not seem sufficient for this feature to
exist at all.

Most of the discussion has been in response to your stubborn refusal
to acknowledge the point.

Meanwhile the downsides are pretty obvious: use the feature, forget
portability, avoid the feature and we just end up with another "auto" or
"gets" - unwanted dross laying about cluttering things up.

So don't freaking use it. But please *try* to understand that there
are *degrees* of portability, and that partial portability can be
better than none at all.