Sizes of Integer Types

[Flash Gordon]

Ian Collins wrote, On 13/09/07 07:38:

Agreed.

However, many 'programmers' assume int is exactly 32 bits and use it as
such thus making their code non-portable. So Chuck's argument could also
be used to argue that int should be removed from the language with
absolutely NO change apart from replacing "those fixed width types" with
"int". The same applies to lots of the rest of the language.

All of my C these says is either embedded or drivers, where size does
matter.

Over the past 20 odd years of embedded development I must have seen
dozens of different typedefs or defines for fixed width types, including
such abominations as WORD. So I was really pleased to see the language
standard define a standard naming convention that enables us to consign
this mishmash to history.

My use of such types would have been when I was doing embedded stuff as
well. The kit was all interfaced using a 16 bit serial bus (1553B if you
are interested) and the data we were interested in was all specified as
being sent as 16 bit scaled numbers which gives more than sufficient
range and precision (for example, even now screen resolutions are below
65536x65536). I'm sure it is easier to interface a 16 bit peripheral
chip (the 1553B interface chip) to a 16 bit processor than a 24 or 32
bit processor. You have power consumption AND heat dissipation limits to
meet, so you need to use "small" processors. Hence the chances of the
code ever being run on something that does NOT have a 16 bit integer
type are as near to none as makes no odds. However, being able to
compile/run some of the code which for simplicity requires a 16 bit
integer on a PC, Sun workstation or similar is useful and using uint16_t
simplifies that.

 

[Chris Hills]

Chris Hills said:

Chris Hills said:

[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
Your copy of the draft is irrelevant.

It is a DRAFT if you are going to mess around with the compiler
you need the standard itself. NOT a draft.

Is it your contention that the final Standard differs from the draft
in this regard?

No. Just that the draft is just that and there are changes between
the draft and the standard. When you are quoting chapter and verse
anything other than the standard has no validity.

Specifically, Kelsey said: "My copy of the draft says that
intN_t types are optional, an implementation is not required to
provide them." As far as I'm aware,

So you are not certain then?

Are you certain that the Standard says implementations are required to
provide intN_t types?

No. I have no idea. What does the standard say (not the draft)

It says:

"These types are optional."

Compare and contrast with the draft, which says:

"These types are optional."

Then quote the standard not the draft.

[...] But the standard *may* be different to the draft at any given
point.

It isn't different at this point.

The quote the standard not the draft.

Two things that are equal to the same thing are equal to each other. *In
this respect*, the Standard is equal to the draft.

Absolutely not.

If what the draft
says about the optional nature of intN_t types is meaningless, then
what the Standard says about the optional nature of intN_t types is
also meaningless.

Not at all. You completely miss the whole point,. One is a meaningless
document (a draft) the other is a ratified standard. Legally one has a
status and the other does not.

It would depend on whether the draft procedure was exactly the same as
the certified procedure. If there is no difference between them, it is
silly to argue that one is superior to the other.

Try that in a court of law.....

 

[Chris Hills]

Please closely examine the above quote from Keith Thompson, and
attempt to detect an underlining.

However as it is a draft any or all of it my be changed from the
published standard. I know for the next standard it is likely we will
remove dome items in C99

 

[Philip Potter]

[snips]

But availability of fixed with types isn't one of them

Oh? So I can use a uint32_t type where what I want is a uint32_t type,
and it will port to other C99 implementations?

No. It _may_ port to _some_ such implementations. It is even worse if I
use multiple such types.

My chess code prefers an 8-bit unsigned type for some things, a 16-bit
unsigned type for others and a 32-bit unsigned type for others. A 64-bit
unsigned type would be a boon as well.

You seem determined to ignore arguments against you here. Your chess code
probably wouldn't benefit from int16_t and co, and *nobody is suggesting you
should use them for this*. int16_t is not useful when you only want something at
least 16 bits wide. It's only useful in that relatively minor case where you
want an exact-width type.

In such a case, you have already said you're happy with masking and guaranteeing
portability to all implmentations. That's fine; it's one way of doing it, and
it's certainly not a bad way. However, if I could look at my code and determine
that it is extremely unlikely to be ported to an implementation which provides
int32_t, and my code would benefit significantly in efficiency and/or
readability terms by being able to use an exact-width type, I'd make that tradeoff.

(One example I can think of for an exact-width type is a DSP application where
the wrap-around arithmetic of 2's complement is exactly what you want. You can
achieve the same result using x %= 2^32 and if(x>=2^31) x-= 2^32, but if you
know you won't ever need that, why bother?)

And yes, you can be fairly sure about some applications that they will always be
on an int32_t platform.

Philip

 

[Richard Heathfield]

Chris Hills said:

Then quote the standard not the draft.

They say the same thing, so it makes no difference.

[...] But the standard *may* be different to the draft at any given
point.

It isn't different at this point.

The quote the standard not the draft.

They say the same thing, so it makes no difference.

Absolutely not.

Excuse me? They say the same thing!

Not at all. You completely miss the whole point,.

No, I see your point very well indeed. It is easily stated: drafts are
not normative. But so what, if the wording is the same as the normative
wording of the Standard?

One is a
meaningless document (a draft) the other is a ratified standard.
Legally one has a status and the other does not.

Nevertheless, They Say The Same Thing (about the subject under
discussion).

Try that in a court of law.....

If I ever have the misfortune to undergo an operation, I trust that it
will be conducted in an operating theatre, not a law court!

Seriously, if a court of law can't tell the sameness between X (written
in document Y) and X (written in document Z), then the law is a ass and
a idiot.

 

[Philip Potter]

Flash Gordon said:

ITYM s/to you/to them/

Of course they are. I freely accept that there may be legitimate reasons
for using intN_t - but there /is/ a portability cost, and that needs to
be made very clear. Naturally, those who are prepared to pay that cost
can expect to reap the perceived benefits.

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

 

[Ian Collins]

Ian Collins said:


And I do.


No, it's not redundant. If I didn't have it, I wouldn't be able to make
the comparison.


The only meaningless bits are the bits that did not make it into the
final Standard.

I assume you haven't worked somewhere where the information manager or
whatever he/she is called doesn't go round sniffing out and shredding
all out of date documents...

 

[Chris Hills]

I assume you haven't worked somewhere where the information manager or
whatever he/she is called doesn't go round sniffing out and shredding
all out of date documents...

The problem with most "religious" debates is the zealots can always
quote a verse (usually out of context) and ignore the bigger picture.

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?

 

[Charlie Gordon]

"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.

 

[Chris Dollin]

No, I see your point very well indeed. It is easily stated: drafts are
not normative. But so what, if the wording is the same as the normative
wording of the Standard?

If you know they are the same, then you can cite the Standard and
not the draft.

If you don't know they are the same, quoting from the draft does
not provide the required authority.

Chris Hills is wrong to call the document "meaningless", of course.
It's not meaningless; it just doesn't carry the necessary authority.
Especially in a legal context.

Exactly.

Nevertheless, They Say The Same Thing (about the subject under
discussion).

See above.

If I ever have the misfortune to undergo an operation, I trust that it
will be conducted in an operating theatre, not a law court!

Seriously, if a court of law can't tell the sameness between X (written
in document Y) and X (written in document Z), then the law is a ass and
a idiot.

(a) IANAL. I would have thought that the /sameness/ wouldn't be the subject
at issue. Wouldn't the question be more about whether the surgeon knowingly
did not follow the certified procedure, not about whether the procedure
followed happened to be the same as the certified one?

(b) Even if Y's X and Z's X were the same, the context provided by Y and Z
could make the /interpretation/ of X different. For example, X might
depend on terms defined differently in Y and Z -- it might use the
term `int`, defined as 16-bit twos-complement in Y and 36-bit ditto
in Z.

Citing the draft is often convenient, and pretty safe when one /knows/ the
areas where the draft and the standard differ, and that they don't
differ "much". But otherwise it's a non-normative guideline, and that's
all.

 

[pete]

Please closely examine the above quote from Keith Thompson, and
attempt to detect an underlining.

I see C99 and two lists of corrections to C99.

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

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

 

[Chris Hills]

Please closely examine the above quote from Keith Thompson, and
attempt to detect an underlining.

I see C99 and two lists of corrections to C99.

It looks like a draft of what will someday be
the corrected version of C99.[/QUOTE]

Some of it may be....

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

Hmmmm that one again. If you pay a subscription you might. The same
as software if you are on support you get updates. Otherwise you have
to buy a new one. You usually only get few updates in the first 12
months.

For books you don't get a free copy when a new edition comes out.

BTW if anyone complains about C99 all they have to do is join the
committee and shape the new standard. However BEWARE eve if a bunch of
enthusiastic users design the next standard it does not mean that the
compiler writers or the industry will implement it.

C99 was not taken up by the industry.

Doing standards is (usually) a thankless task.

 

[Richard Heathfield]

Ian Collins said:

Richard Heathfield wrote:
I assume you haven't worked somewhere where the information manager or
whatever he/she is called doesn't go round sniffing out and shredding
all out of date documents...

You assume correctly. In fact, I had no idea that such sites
existed. If you ever come across another one, apply for a preservation
order.

 

[Richard Heathfield]

Chris Hills said:

The problem with most "religious" debates is the zealots can always
quote a verse (usually out of context) and ignore the bigger picture.

I'm not trying to ignore any bigger pictures. But this isn't about
bigger pictures. This is about whether the draft does or does not say
the same thing as the published Standard about whether intN_t types are
optional. If it doesn't, fine, I'll eat humble pie and be glad of it,
because I'll have learned something. But right now it seems to me that
you're reading a different published Standard to the one I paid ANSI
for, back in early 2000.

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.

Could you please point out the paragraphs in the standard that alter the
meaning of the one paragraph I quoted?

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?

No, I didn't. Perhaps you'd care to elaborate by posting the paragraph
number. (I do have the published Standard, of course, so that will be
sufficient.)

 

[Richard Heathfield]

Chris Hills said:

C99 was not taken up by the industry.

Right. So why bother to argue about it?

 

[Ian Collins]

Ian Collins said:


You assume correctly. In fact, I had no idea that such sites
existed. If you ever come across another one, apply for a preservation
order.

ISO 9000.

 

[Richard Bos]

On Tue, 11 Sep 2007 18:59:20 -0700, Keith Thompson wrote:


Because uint32_t et al are broken beyond redemption and must be avoided at
all costs. Yes, we're agreed.

Kelsey, either you are being deliberately obtuse, or you really _are_ so
stupid that you think the situation is that black-and-white. Either way,
I see no reason to discuss this with you any more.

Richard

 

[Richard Bos]

Ian Collins said:

Richard Heathfield wrote:
So one must exercise care even in C90 (or accept that one's code is
not portable to certain kinds of implementation). C99 has all of the
C90 portability issues, and adds a whole bunch of new ones.

But availability of fixed wi[d]th types isn't one of them,

It *is*, if people are lured into using C99's named types unnecessarily,
because they (erroneously) believe that this somehow makes their code
more portable than is in fact the case.

Certainly any programmer should understand just what uint32_t is
before using it. As I've said before, it would have made a lot more
sense to call it uint_exact32_t; the simple name it has now just makes
it too tempting to use where it's not really needed.

*But* I think that having (optional) exact-width types is a good idea,
for those fairly rare cases where that happens to be exactly what you
need.

You, sir, hit the nail on the head both times.

Richard

 

[Richard Heathfield]

Ian Collins said:

ISO 9000.

Oh, *that*. Nah, when the ISO guys came round, we just didn't show them
the contents of our desk drawers.

 

[Chris Hills]

Chris Hills said:



Right. So why bother to argue about it?

I am having to look at where next. Also C99 was partially taken up.
Most compilers are somewhere between C95 and C99

Also MISRA-C is having to decide if we reference C95 or C99 or look at
C2*