Sizes of Integer Types

[Bob Timpkinson]

Hi,

I have a 32-bit machine... Is there anyway I can get gcc to use the
following integer sizes?
char: 8 bits
short: 16 bits
int: 32 bits
long: 64 bits
long long: 128 bits

Thanks!

Bob.

[Richard Heathfield]

Chris Hills said:

In article <4e************@spanky.localhost.net>, Kelsey Bjarnason
<kb********@gmail.comwrites

>>[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.hheader, 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? 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, this remains true in the final Standard. I
refer you specifically to 7.18(4): "An implementation shall provide
those types described as ``required'', but need not provide any of the
others (described as ``optional'')."

It seems to me that your objection is nebulous.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Chris Hills]

In article <ou*********************@bt.com>, Richard Heathfield
<rj*@see.sig.invalidwrites

>Chris Hills said:

>In article <4e************@spanky.localhost.net>, Kelsey Bjarnason
<kb********@gmail.comwrites

>>>[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.hheader, 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?

this remains true in the final Standard. I
refer you specifically to 7.18(4): "An implementation shall provide
those types described as ``required'', but need not provide any of the
others (described as ``optional'')."

It seems to me that your objection is nebulous.

So it's ok to quote chapter and verse and be pedantic but use a draft
not the proper standard?

Don't ever go to court or they will throw you out with logic like that


--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

[Kelsey Bjarnason]

[snips]

On Wed, 12 Sep 2007 20:31:56 +1200, Ian Collins wrote:

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

Aha! uint8_t, uint16_t, uint32_t. Very good. Now, I'm guaranteed that
the relevant types will exist on any given implementation, right? No?
Ah. Maybe I can use, oh, uintleast8_t or whatever it is, so that even if
the type ends up being 32 bits, it is _at least_ the 8 I need? Hmm...
so's a char, and a short's at least 16 and a long's at least 32. So I'm
better off to just pretend these new int types don't exist at all, because
I simply *cannot* rely on them.

>, it has always
been an issue. All C99 does is provide a standardised set of names.

If they're standardized, and we're not talking about a freestanding
implementation or some other oddball construct, then they exist, right?
Every conforming implementation will have them, right?

Nope. Not required. When "standard" ends up meaning "may or may not
exist, take a guess and pray" the term gets diluted somewhat.

If your code is processing a stream of say 16 bit data, you can either
assume the existence of a 16 (or 8) bit type

Like char and short? Oh, they're not required to be 8 and 16 bits, just
at least 8 and 16 bits. Meaning we've had perfectly good types for this
sort of thing since what, K&R?

The new int types were a potential boon, a way of saying "I don't care
what the machine supports natively, I want an 8 bit type even if the
little rotter needs to be emulated. I'll accept the speed overhead as
a tradeoff to the space overhead."

Instead it's a half-functioning accident which buys me absolutely nothing
of value, as far as I can see.

[Kelsey Bjarnason]

[snips]

On Wed, 12 Sep 2007 14:08:07 +0000, Richard Bos wrote:

>Indeed. And yet you can't rely on that, because the new int types may not
exist *at all* on the new platform.

In which case, the program you want can't be easily written for that
platform anyway.

True, but then I can code it once, using types which actually _do_ exist,
and have it run on all implementations.

Try that with the new int types. Oh, wait, you can't, because they're not
even required to exist.

[Kelsey Bjarnason]

[snips]

On Wed, 12 Sep 2007 11:56:53 +0000, Richard Bos wrote:

>Exactly the point. We *already* have, without the new int types, a
functional set of types which are _at least_ n bits wide.

Yes. And _exactly_ n bits wide?

Nope. But we don't have that with the new int types, either, unless you
care to show where every implementation is _required_ to support, say,
uint8_t, uint16_t and uint32_t.

Ah, right. They're not. So this "exactly" nonsense is just that -
nonsense - as you can't expect it to work. At least the other way you
_do_ expect it to work.

>They have all the utility of void main() - they'll work, somewhere, on
some compiler, for some definition of "work", but you can't rely on
them working _at all_ on an arbitrary compiler.

void main() adds no functionality. Exact-width types do.

If void main adds no functionality, why's it so popular? As to the new
int types, explain what functionality they add when you can't even rely on
them existing. You *cannot* write code that uses them and expect it to
work on an arbitrary implementation, whereas you _can_ do this with
existing types.

Okay, in a strict sense they do add new functionality: they impose limits
on where code can be compiled, a feat which I don't think was ever managed
before by something as basic as an integer type.

Then again, I'm not really sure why one would think of this as a benefit.

[Kelsey Bjarnason]

[snips]

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

The lack of portability is imposed by the requirement to use a type
that's exactly 32 bits.

Which means you've already limited your compiler choice, which means you
already know the sizes involved which means _at most_ using a typedef of
your own to achieve exactly what's needed - 32 bit ints on this one, 32
bit longs on that one. The new int types are simply not needed here.

So, we're agreed, in this case, the int types are a complete waste of
paper. Yet this is, apparently, the only time you can rely on them. So
we're agreed; they're useless.

One more time, code that uses uint32_t cannot be 100% portable.

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

But
it's more portable than *your* code that assumes unsigned int is exactly
32 bits, or another version of your code that assumes unsigned long is
exactly 32 bits.

Use a typedef; it's pretty trivial and people have been doing it for what,
30 years?

Oh, I see. The new int types are intended to accomplish something already
done by long practice, but accomplish it in such a way that code relying
on the new approach falls on its face just because you change platforms,
is that what you're saying? No thanks, I'll stick with what works - and
the new int types ain't it.

[Kelsey Bjarnason]

[snips]

On Wed, 12 Sep 2007 16:32:09 +0100, Chris Hills wrote:

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

No freakin' kidding. Why do you think I *stated* *explicitly* that it was
being quoted from the draft, rather than claiming it was from the standard
itself? Maybe, perhaps, just *could be* I recognize the possibility it
could have changed between draft and final? Maybe? Possibly?

[Ben Pfaff]

Kelsey Bjarnason <kb********@gmail.comwrites:

Maybe I can use, oh, uintleast8_t or whatever it is, so that even if
the type ends up being 32 bits, it is _at least_ the 8 I need? Hmm...
so's a char, and a short's at least 16 and a long's at least 32. So I'm
better off to just pretend these new int types don't exist at all, because
I simply *cannot* rely on them.

The point of the types with "least" in their names is not to be
"at least" those sizes. It is to be the narrowest (least width)
type with at least that size. int_least16_t is different from
short in that short could be 32 bits on a machine that has a
16-bit char, but int_least16_t would be char on that machine.
--
char a[]="\n .CJacehknorstu";int putchar(int);int main(void){unsigned long b[]
={0x67dffdff,0x9aa9aa6a,0xa77ffda9,0x7da6aa6a,0xa6 7f6aaa,0xaa9aa9f6,0x11f6},*p
=b,i=24;for(;p+=!*p;*p/=4)switch(0[p]&3)case 0:{return 0;for(p--;i--;i--)case+
2:{i++;if(i)break;else default:continue;if(0)case 1:putchar(a[i&15]);break;}}}

[Al Balmer]

On Wed, 12 Sep 2007 07:59:26 +0000, Richard Heathfield
<rj*@see.sig.invalidwrote:

>Ian Collins said:

>Kelsey Bjarnason wrote:

>>On Tue, 11 Sep 2007 23:55:08 +0000, Al Balmer wrote:

On Tue, 11 Sep 2007 15:23:25 -0700, Kelsey Bjarnason
<kb********@gmail.comwrote:

Exactly the point. We *already* have, without the new int types, a
functional set of types which are _at least_ n bits wide. With the
new int types, we have... oh, yes, a functional set of types which
are _at
least_ n bits wide. Those types? char, short, int, long (and now
long long).
They are not guaranteed to be the same size on different platforms,
and sometimes you want exact size.

Indeed. And yet you can't rely on that, because the new int types
may not exist *at all* on the new platform.

Then you either add them, or give up as you can't port the code.

No, you write the code so as not to need them. In other words, you write
your code *not* to rely on exact size.

Kelsey is absolutely right. If a type isn't guaranteed to be provided by
the implementation, one cannot use it in code that is required to be
portable to arbitrary implementations.

Fortunately, my code never has to be ported to arbitrary
implementations. A dozen or so will suffice :-)

--
Al Balmer
Sun City, AZ

[Bart van Ingen Schenau]

Kelsey Bjarnason wrote:

[snips]

On Tue, 11 Sep 2007 17:59:28 -0500, Stephen Sprunk wrote:

>You're still missing the point. If I want to write code that is only
portable to systems that have a 32-bit integer type, then the easiest
way to get that data type is to use [u]int32_t.

Which deals with one type. You can, of course, guarantee that this
system
_also_ has, oh, 8 bit integer types, right? No? So all that code
using uint8_t now has to be scrapped or rewritten, because the types
simply aren't available.

No. It is not an all-or-nothing proposition.
If I need a type with exactly 32 bits somewhere in a program, I use
[u]int32_t *at that location*. For all other variables that don't
require an exact width, I use the regular types (or the [u]int_{fast
least}N_t types).

If I need exact-width types of 8, 16 and 32 bits, then either I am doing
something wrong, or my program in inherently non-portable.

>
By the time you get to the point where all these new types make sense,
you've essentially restricted C to existing only on 32-bit x86
machines or
close equivalents. Hardly sensible.

Except that uint8_t does not need to exist if I only needed a 32-bit
exact width type. So my program is still portable to platforms that do
provide 32-bit integers, but not 8-bit integers.

>

> Note that I didn't say
an integer type of "at least" 32 bits, which is what I'd get if I
used
"long". If I'm relying on a variable being exactly 32 bits, no more
or less, I cannot use a long for that purpose.

Nor can you rely on the new types, as they may well simply not exist
on
a given implementation. Yes, and?

If you used the exact-width types correctly (i.e. only when least-width
is not good enough), then you find out at compile-time that your
program can not be ported to that platform without major
rethinking/rework.

If you stuck to the existing types, at best you had found out with a
code review. More likely during testing and at worst only after
delivery of the system to your customers.

One area where the exact-width types can be beneficial, IMHO, is in the
implementation of protocol stacks, where the protocol definition is
octet oriented.
If your target platform does not have an 8-bit data type, you will have
to jump through a lot of complicated hoops to implement the protocol
correctly (where the hoops may depend on the width of the types that
you do have). Adding all these hoops to your implementation while there
is no need for them (all targeted platform support an 8-bit type) will
only increase your development cost and decrease performance.

Bart v Ingen Schenau
--
a.c.l.l.c-c++ FAQ: http://www.comeaucomputing.com/learn/faq
c.l.c FAQ: http://www.eskimo.com/~scs/C-faq/top.html
c.l.c++ FAQ: http://www.parashift.com/c++-faq-lite/

[Bart van Ingen Schenau]

Kelsey Bjarnason wrote:

[snips]

On Tue, 11 Sep 2007 16:43:39 -0700, Keith Thompson wrote:

>>>Then you shouldn't have used uint32_t.

Exactly the point - *why* doesn't it exist?

If it doesn't exist, it's because the implementation doesn't have a
predefined 32-bit unsigned type.

Making the use of the type effectively impossible, as you can no long
expect your code to compile, on a conforming compiler, except by
accident. Not a great leap forward for C portability.

>If you're writing code intended to be maximally portable, then you
don't want or need a type that's exactly 32 bits.

Don't _need_ one, perhaps. Want is another matter. For example, take
a chess program; it would be very nice to specify an 8-bit type for
some purposes, a 32-bit type for others and a 64-bit for some other
purposes.

You don't *need* exact-sized types, of course. If char, int and long
are all 32 bits, you may end up wasting a good whack of space in
storing transition tables and the like but the program will still
work... it's just rather likely to work somewhat less efficiently as
the storage overhead skyrockets.

As the code does not require an exact width, you *don't use* the types
uint8_t, uint32_t and uint64_t. Instead you use the more appropriate
uint_least8_t, uint_least32_t and uint_least64_t.

Then you can even port the program to a processor that has 8-bit char,
64-bit short, 128-bit int, 256-bit long and 512-bit long long without
wasting too much space.
Try doing that without using typedefs.

<snip>

>
Because unlike that abortion, I can rely on *my* typedefs actually
existing.

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.

>

>None of these will work on System Z, of course; that's not the point.
Either you accept the fact that your software isn't 100% portable

But why go out of your way to limit its portability, by adopting
things
which simply will not exist?

It is not me who restricted the portability. It is the guy who wrote
down the requirements for the software I am making that restricted the
portability by requiring the use of an exact-width type.
It is not my fault that System Z can't fulfil the preconditions needed
for using the software.

Do you also complain that the device driver for a token-ring network
adapter is not portable to systems that can't interface with such a
device?

Bart v Ingen Schenau
--
a.c.l.l.c-c++ FAQ: http://www.comeaucomputing.com/learn/faq
c.l.c FAQ: http://www.eskimo.com/~scs/C-faq/top.html
c.l.c++ FAQ: http://www.parashift.com/c++-faq-lite/

[Keith Thompson]

Richard Heathfield <rj*@see.sig.invalidwrites:
[...]

No, you write the code so as not to need them. In other words, you write
your code *not* to rely on exact size.

Ideally, yes.

Kelsey is absolutely right. If a type isn't guaranteed to be provided by
the implementation, one cannot use it in code that is required to be
portable to arbitrary implementations.

And if that were all Kelsey had said, I would agree completely.

But he's also saying that *because* the exact-width types aren't 100%
portable, they're completely useless. I disagree. They can be useful
in some contexts; those contexts do not allow for portability to
arbitrary implementations. Sometimes portability to all
implementations that support *some* 32-bit integer type is good enough
-- and better than portability to all implementations where int is 32
bits, or to all implementations where long is 32 bits.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <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."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Keith Thompson]

Richard Heathfield <rj*@see.sig.invalidwrites:

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.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <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."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Keith Thompson]

jacob navia <ja***@jacob.remcomp.frwrites:

Kelsey Bjarnason wrote:

>[snips]
On Wed, 12 Sep 2007 10:58:06 +0100, Philip Potter wrote:

[...]

>Now add in a new one:

>>Integer type | SizeA | SizeB | SizeC
char | 8 | 8 | 64
short | 16 | 16 | 64
int | 32 | 16 | 64

long | 64 | 32 | 64

[...]

Great!

Now, can you name a platform where sizeof char is 64 bits???

No, I can't, though such a platform is possible. (I've heard of
platforms, namely DSPs, with 32-bit char; a 64-bit DSP is entirely
plausible.)

But I've actually used systems with 8-bit char, 64-bit short, 64-bit
int, and 64-bit long, which makes the point equaly well.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <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."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Keith Thompson]

Kelsey Bjarnason <kb********@gmail.comwrites:

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

>The lack of portability is imposed by the requirement to use a type
that's exactly 32 bits.

Which means you've already limited your compiler choice, which means you
already know the sizes involved which means _at most_ using a typedef of
your own to achieve exactly what's needed - 32 bit ints on this one, 32
bit longs on that one. The new int types are simply not needed here.

No, they're not absolutely needed, but they can be useful in some
limited contexts.

So, we're agreed, in this case, the int types are a complete waste of
paper. Yet this is, apparently, the only time you can rely on them. So
we're agreed; they're useless.

>One more time, code that uses uint32_t cannot be 100% portable.

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

Do *not* put words in my mouth.

Are you asserting that anything that's not 100% portable is useless?
Really?

> But
it's more portable than *your* code that assumes unsigned int is exactly
32 bits, or another version of your code that assumes unsigned long is
exactly 32 bits.

Use a typedef; it's pretty trivial and people have been doing it for what,
30 years?

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.

Oh, I see. The new int types are intended to accomplish something already
done by long practice, but accomplish it in such a way that code relying
on the new approach falls on its face just because you change platforms,
is that what you're saying? No thanks, I'll stick with what works - and
the new int types ain't it.

Good for you. Write your own code any way you like.

Listen carefully. Nobody has claimed that the uintN_t types are 100%
portable; they clearly are not. Repeatedly pointing out that they're
not 100% portable, as if you were refuting something, is useless.

If *you* don't need a type that's *exactly* 32 bits wide, then *you*
definitely shouldn't use uint32_t. Happy?

--
Keith Thompson (The_Other_Keith) ks***@mib.org <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."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Richard Heathfield]

Chris Hills said:

In article <qs******************************@bt.com>, Richard
Heathfield <rj*@see.sig.invalidwrites

>>Chris Hills said:

>>In article <ou*********************@bt.com>, Richard Heathfield
<rj*@see.sig.invalidwrites
Chris Hills said:

In article <4e************@spanky.localhost.net>, Kelsey Bjarnason
<kb********@gmail.comwrites
>>[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.hheader, 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."

>>Chapter and verse, please.

You tell me what the STAndard (NOT A DRAFT ) says

Since you ask what the Standard says, am I to presume that you only have
a draft? Anyway, it says "These types are optional." Just like the
draft.

<snip>

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

It isn't different at this point.

The only way you can know is by checking the standard. The
draft is meaningless.

Two things that are equal to the same thing are equal to each other. *In
this respect*, the Standard is equal to the draft. 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 having the standard is because it is expensive is not an
acceptable reason.

You're preaching to the choir. I bought a copy of the C99 Standard as
soon as it came out.

<snip>

How would you feel if a surgeon was operating on you using a draft
procedure rather than the certified procedure because the certified
one costs money?

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.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Flash Gordon]

Richard Heathfield wrote, On 12/09/07 09:21:

Ian Collins said:

>Richard Heathfield wrote:

<snip>

>>Kelsey is absolutely right. If a type isn't guaranteed to be provided
by the implementation, one cannot use it in code that is required to
be portable to arbitrary implementations.

Then you have the concept of standard conforming, non-portable code.

Yes, of course. C99 makes it not only possible but easy to write such
code. Not only does the use of C99 features render your code
non-portable to C90 implementations, but it can even render your code
non-portable to *other C99 implementations*.

Yes, but if you know this and have good reasons this is not a problem
just a known limitation.

This is true of C90, too, but in a much more limited way. For example, I
have occasionally had cause to define an array of UCHAR_MAX + 1
unsigned long ints, which seems perfectly unobjectionable and indeed is
quite okay on what you might call "normal" implementations - but on
reflection it's easy to see how it could break. If CHAR_BIT is 32, say,
then that array is suddenly rather on the large side.

I've worked on systems where CHAR_BIT is 16 and the processor has a 16
bit address bus and some of the address space allocated by the processor
manufacturer for special purposes. So your array is *guaranteed* not to fit.

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.

So you are allowed to ignore the portability issues that do not affect
you but those who have different portability requirements are not
allowed to limit themselves to the implementations of interest to you?

I've had very good reasons to limit myself to implementations which
support a 16 bit integer type with no padding, and at the time I *knew*
that there were implementations with no type smaller than 24 bits. My
employer would not have been pleased if I spent extra time making it
portable to implementations it was *very* unlikely to be ported to.
--
Flash Gordon

[Flash Gordon]

Richard Heathfield wrote, On 12/09/07 10:19:

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.

If you know the portability limitations of exact width types then using
them makes your code portable to exactly the correct extent.

>it has always been an issue.

...but not a huge one - certainly not huge enough to justify C99's
muddying the waters of portability.

Others obviously disagree.

>All C99 does is provide a standardised set of names.

...which don't actually perform any useful function that I can see.

It makes it simple to make code that relies on exact width types to be
portable to all the implementations it is required to be portable to and
guarantees that it will fail to compile on implementations it is
definitely not portable to. This is a very useful property.

>If your code is processing a stream of say 16 bit data, you can either
assume the existence of a 16 (or 8) bit type, or come up with
something horribly complex to cope with systems where integer types
are a multiple of something other than eight.

Indeed. The first choice is a natural one, but has its limitations, as
we have already seen. The second choice is a harder road, but it is
unavoidable if maximal portability is a prerequisite.

Maximal portability is not always a requirement. Sometimes portability
to a specific range of machines is sufficient, and fixed width types
make providing that degree of portability and ensuring that people are
not mislead by the application compiling where it will not work easy.
--
Flash Gordon

[Richard Heathfield]

Flash Gordon said:

Richard Heathfield wrote, On 12/09/07 09:21:

>Ian Collins said:

<snip>

>>Then you have the concept of standard conforming, non-portable code.

Yes, of course. C99 makes it not only possible but easy to write such
code. Not only does the use of C99 features render your code
non-portable to C90 implementations, but it can even render your code
non-portable to *other C99 implementations*.

Yes, but if you know this and have good reasons this is not a problem
just a known limitation.

As long as it is a *known* limitation, it is not a problem.

>This is true of C90, too, but in a much more limited way. For
example, I have occasionally had cause to define an array of
UCHAR_MAX + 1 unsigned long ints, which seems perfectly
unobjectionable and indeed is quite okay on what you might call
"normal" implementations - but on reflection it's easy to see how it
could break. If CHAR_BIT is 32, say, then that array is suddenly
rather on the large side.

I've worked on systems where CHAR_BIT is 16 and the processor has a 16
bit address bus and some of the address space allocated by the
processor manufacturer for special purposes. So your array is
*guaranteed* not to fit.

Yes, absolutely. My point entirely.

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

So you are allowed to ignore the portability issues that do not affect
you but those who have different portability requirements are not
allowed to limit themselves to the implementations of interest to you?

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.

<snip>

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Ian Collins]

Kelsey Bjarnason wrote:

[snips]

On Wed, 12 Sep 2007 20:31:56 +1200, Ian Collins wrote:

>If your code is processing a stream of say 16 bit data, you can either
assume the existence of a 16 (or 8) bit type

Like char and short? Oh, they're not required to be 8 and 16 bits, just
at least 8 and 16 bits. Meaning we've had perfectly good types for this
sort of thing since what, K&R?

So what would you rather have, code using short that compiles happily on
a system where short is 32 or 18 bits, but then fails to work (possibly
in a less than obvious way) or code that uses int16_t and won't compile?

I for one would prefer the latter.

--
Ian Collins.

[Al Balmer]

On Wed, 12 Sep 2007 14:50:41 +0000, Richard Heathfield
<rj*@see.sig.invalidwrote:

>Chris Hills said:

>In article <4e************@spanky.localhost.net>, Kelsey Bjarnason
<kb********@gmail.comwrites

>>>[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.hheader, 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? 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, this remains true in the final Standard. I
refer you specifically to 7.18(4): "An implementation shall provide
those types described as ``required'', but need not provide any of the
others (described as ``optional'')."

Yes, but that is not what Kelsey said. What he said disagrees with my
copy of the C99 standard (and my copy of the 9899:TC2 draft.)

Certain of the stdint types are required, and others are required *if*
the implementation is able to provide them. For example, for the exact
width types:

7.18.1.1(3)
"These types are optional. However, if an implementation provides
integer types with widths of 8, 16, 32, or 64 bits, no padding bits,
and (for the signed types) that have a two’s complement
representation, it shall define the corresponding typedef names."

and for the minimum-width types,
7.18.1.2(3)
"The following types are required:
int_least8_t
int_least16_t
int_least32_t
int_least64_t
uint_least8_t
uint_least16_t
uint_least32_t
uint_least64_t
All other types of this form are optional."

--
Al Balmer
Sun City, AZ

[Flash Gordon]

Kelsey Bjarnason wrote, On 12/09/07 17:40:

[snips]

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

>The lack of portability is imposed by the requirement to use a type
that's exactly 32 bits.

Which means you've already limited your compiler choice,

Yes.

which means you
already know the sizes involved

You do not know *which* type will be the required width, or you may be
targeting multiple implementations which have a 32 bit type, but on each
implementation it is a *different* one of the base types.

which means _at most_ using a typedef of
your own to achieve exactly what's needed - 32 bit ints on this one, 32
bit longs on that one. The new int types are simply not needed here.

The types make it a lot simpler and less error prone since you don't
need to construct the mess of conditional defines and try to find a way
to prove that it will always select the correct type if it exist or
cause a compilation failure if it does not.

So, we're agreed, in this case, the int types are a complete waste of
paper.

No, you keep asserting that other peoples reasons for using them don't
count.

I *could* write the entire program in machine code with a hex editor so
we don't need C at all so C is a complete waste. That is the argument
you are making.

Yet this is, apparently, the only time you can rely on them. So
we're agreed; they're useless.

No, you assert that because for your purposes they are of no use. That
does not mean that others cannot have different requirements.

>One more time, code that uses uint32_t cannot be 100% portable.

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

Is your code portable to all systems? Can I run ALL of your code on the
card I used to program for with 16 bit char, short and int, 8K of ROM
for the program and 8K of RAM for the data?

> But
it's more portable than *your* code that assumes unsigned int is exactly
32 bits, or another version of your code that assumes unsigned long is
exactly 32 bits.

Use a typedef; it's pretty trivial and people have been doing it for what,
30 years?

Oh, I see. The new int types are intended to accomplish something already
done by long practice, but accomplish it in such a way that code relying
on the new approach falls on its face just because you change platforms,
is that what you're saying?

The old approach would fail on implementations without a type of the
required type. It would either fail by allowing the code to compile on a
platform where it will NOT work or it will fail (by your definition)
because it does not compile.

No thanks, I'll stick with what works - and
the new int types ain't it.

Don't use them. Those for whom they *are* the correct types, who do not
need to port to all possible implementations, will use them secure in
the knowledge that they provide exactly the correct functionality.
--
Flash Gordon

[Richard Heathfield]

Al Balmer said:

On Wed, 12 Sep 2007 14:50:41 +0000, Richard Heathfield
<rj*@see.sig.invalidwrote:

>>Chris Hills said:

>>In article <4e************@spanky.localhost.net>, Kelsey Bjarnason
<kb********@gmail.comwrites

<snip>

>>>>
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? 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, this remains true in the final
Standard. I refer you specifically to 7.18(4): "An implementation
shall provide those types described as ``required'', but need not
provide any of the others (described as ``optional'')."

Yes, but that is not what Kelsey said. What he said disagrees with my
copy of the C99 standard (and my copy of the 9899:TC2 draft.)

Fine - but that's a different argument. My beef with Chris is that he's
saying the draft is meaningless *even though it agrees with the
Standard*.

Certain of the stdint types are required, and others are required *if*
the implementation is able to provide them. For example, for the exact
width types:

7.18.1.1(3)
"These types are optional. However, if an implementation provides
integer types with widths of 8, 16, 32, or 64 bits, no padding bits,
and (for the signed types) that have a two’s complement
representation, it shall define the corresponding typedef names."

ISO/IEC 9899:1999 reads:

3 These types are optional. However, if an implementation provides
integer types with widths of 8, 16, 32, or 64 bits, it shall define the
corresponding typedef names.

n869.txt reads:

[#3] These types are optional. However, if an |
implementation provides integer types with widths of 8, 16, |
32, or 64 bits, it shall define the corresponding typedef |
names.

Word for word the same.

<snip>

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Ian Collins]

Richard Heathfield wrote:

>
Fine - but that's a different argument. My beef with Chris is that he's
saying the draft is meaningless *even though it agrees with the
Standard*.

To be able to make that statement, you have to have a copy of the
standard to compare, having that copy would make the draft redundant, if
not meaningless.

--
Ian Collins.

[jacob navia]

Kelsey Bjarnason wrote:

>
Fine. In future, I'll refer to such things as "being pulled from Chris
Hills' rectal orifice" so there will be no confusion. Happy now?

Have you maybe noticed that USENET is not the toilet?

Next time, when you feel like insulting people this way
maybe you go to the toilet instead of posting stuff?

Mr Hills neither insulted you, nor was in ANY WAY offensive.
He took issue of you using a draft and not the standard itself,
a minor objection.

Your answer is of such disproportionate baseness that
only reveals what you really are.

[Al Balmer]

On Wed, 12 Sep 2007 20:12:01 +0000, Richard Heathfield
<rj*@see.sig.invalidwrote:

>Fine - but that's a different argument.

Agreed. I just didn't want him to think he got away with it <g>.

My beef with Chris is that he's
saying the draft is meaningless *even though it agrees with the
Standard*.

I don't know where I read it, but I think the draft is simply a
compilation of the original C99 and the TCs, and errata. As such, it
includes the current standard.

Ah, here we go:
"The lastest (sic) publically (sic) available version of the standard
is the combined C99 + TC1 + TC2, WG14 N1124, dated 2005-05-06. This is
a WG14 working paper, but it reflects the consolidated standard at the
time of issue."
http://www.open-std.org/jtc1/sc22/wg14/www/standards

That's why I never worried about differences in the draft. I own a
copy of C99, but I use the draft, because it includes the TCs.

--
Al Balmer
Sun City, AZ

[A N Other]

On 12 Sep 2007 at 21:48, jacob navia wrote:

Kelsey Bjarnason wrote:

>>
Fine. In future, I'll refer to such things as "being pulled from Chris
Hills' rectal orifice" so there will be no confusion. Happy now?

Have you maybe noticed that USENET is not the toilet?

You say that, but plenty of people fill it with shit. Spam about
lcc-win32 for example.

>
Next time, when you feel like insulting people this way
maybe you go to the toilet instead of posting stuff?

Mr Hills neither insulted you, nor was in ANY WAY offensive.
He took issue of you using a draft and not the standard itself,
a minor objection.

Your answer is of such disproportionate baseness that
only reveals what you really are.

Rubbish. Chris Hills behaved like a complete idiot.

[Richard Heathfield]

Ian Collins said:

Richard Heathfield wrote:

>>
Fine - but that's a different argument. My beef with Chris is that
he's saying the draft is meaningless *even though it agrees with the
Standard*.

To be able to make that statement, you have to have a copy of the
standard to compare,

And I do.

having that copy would make the draft redundant,

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

if not meaningless.

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

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Kelsey Bjarnason]

On Thu, 13 Sep 2007 07:37:57 +1200, Ian Collins wrote:

Kelsey Bjarnason wrote:

>[snips]

On Wed, 12 Sep 2007 20:31:56 +1200, Ian Collins wrote:

>>If your code is processing a stream of say 16 bit data, you can either
assume the existence of a 16 (or 8) bit type

Like char and short? Oh, they're not required to be 8 and 16 bits, just
at least 8 and 16 bits. Meaning we've had perfectly good types for this
sort of thing since what, K&R?

So what would you rather have, code using short that compiles happily on
a system where short is 32 or 18 bits, but then fails to work (possibly
in a less than obvious way) or code that uses int16_t and won't compile?

I'd rather have code that compiles and works. Maybe that means masking,
fine, I can live with that if I have to. At least I'd only have one code
path to maintain, and it would work on _any_ conforming implementation.

[Kelsey Bjarnason]

[snips]

On Wed, 12 Sep 2007 19:55:41 +0200, Bart van Ingen Schenau wrote:

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.

[Kelsey Bjarnason]

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

--
Are you really this stupid, or is your medication wearing off?
-- David Rice

[Richard Heathfield]

Kelsey Bjarnason said:

On Thu, 13 Sep 2007 07:45:09 +1200, Ian Collins wrote:

<snip>

>That's gone from nonsense to total bollocks. Kindly show how PPC or
SPARC are "close equivalents" to x86.

Already did. Pay attention.

Both Ian and Kelsey are bright bunnies. I wish they could both conduct
this debate with a little more respect for each other.

Come on, guys - lighten up a little. Demonstrate that it's possible to
disagree with someone without insulting them.

<snip>

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[pete]

Kelsey Bjarnason wrote:

Unless you use them, at which point your code's portability has gone
straight into the crapper. Yay, C!
Yesterday you were portable across
endless systems, now you're portable across... well...
who the hell knows, because all bets are off.

Now you're portable across implementations that support those types.
Without the standardization of the optional types,
then you would not even be portable across those.

That was explained to me, a long time ago, by one of the smart guys,
either on this newsgroup or comp.std.c

Personally, I value the relative simplicity of the C89 standard.

--
pete

[Keith Thompson]

Kelsey Bjarnason <kb********@gmail.comwrites:

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

uint32_t isn't defined on an implementation that has no predefined
32-bit integer type. Good, you agree with me.

Are you *deliberately* missing the point?

--
Keith Thompson (The_Other_Keith) ks***@mib.org <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."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[pete]

Keith Thompson wrote:

N1124 is the post-C99 draft you're referring to; it combines the C99
standard with TC1 and TC2, with all differences from the official C99
marked by change bars.

What is N1124 a draft of?

--
pete

[Keith Thompson]

pete <pf*****@mindspring.comwrites:

Keith Thompson wrote:

>N1124 is the post-C99 draft you're referring to; it combines the C99
standard with TC1 and TC2, with all differences from the official C99
marked by change bars.

What is N1124 a draft of?

The Committee. semi 8-)}

The header on each page says:

WG14/N1124 Committee Draft -- May 6, 2005 ISO/IEC 9899:TC2

I suppose it could be considered to be a draft of the next version of
the C standard.

If that's really a serious question, comp.std.c would be the place to
ask it.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <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."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Ian Collins]

Kelsey Bjarnason wrote:

On Thu, 13 Sep 2007 07:37:57 +1200, Ian Collins wrote:

>Kelsey Bjarnason wrote:

>>[snips]

On Wed, 12 Sep 2007 20:31:56 +1200, Ian Collins wrote:

If your code is processing a stream of say 16 bit data, you can either
assume the existence of a 16 (or 8) bit type
Like char and short? Oh, they're not required to be 8 and 16 bits, just
at least 8 and 16 bits. Meaning we've had perfectly good types for this
sort of thing since what, K&R?

So what would you rather have, code using short that compiles happily on
a system where short is 32 or 18 bits, but then fails to work (possibly
in a less than obvious way) or code that uses int16_t and won't compile?

I'd rather have code that compiles and works. Maybe that means masking,
fine, I can live with that if I have to. At least I'd only have one code
path to maintain, and it would work on _any_ conforming implementation.

But what would you call your 16 bit type?

--
Ian Collins.

[Ian Collins]

Richard Heathfield wrote:

Kelsey Bjarnason said:

>On Thu, 13 Sep 2007 07:45:09 +1200, Ian Collins wrote:

<snip>

>>That's gone from nonsense to total bollocks. Kindly show how PPC or
SPARC are "close equivalents" to x86.

Already did. Pay attention.

Both Ian and Kelsey are bright bunnies. I wish they could both conduct
this debate with a little more respect for each other.

Come on, guys - lighten up a little. Demonstrate that it's possible to
disagree with someone without insulting them.

I haven't, I've just stated the plain truth, x86, SPARC and PPC are in
no way close equivalents.

--
Ian Collins.

[Richard Heathfield]

Ian Collins said:

Richard Heathfield wrote:

>Kelsey Bjarnason said:

>>On Thu, 13 Sep 2007 07:45:09 +1200, Ian Collins wrote:

<snip>

>>>That's gone from nonsense to total bollocks. Kindly show how PPC or
SPARC are "close equivalents" to x86.
Already did. Pay attention.

Both Ian and Kelsey are bright bunnies. I wish they could both
conduct this debate with a little more respect for each other.

Come on, guys - lighten up a little. Demonstrate that it's possible
to disagree with someone without insulting them.

I haven't, I've just stated the plain truth, x86, SPARC and PPC are in
no way close equivalents.

I am happy to accept your claim that you have spoken truth, but I cannot
agree that it was either just or plain. See above quote of your words.
(I deliberately quoted /both/ insults, yours as well as his.)

Anyway, I've said my bit, and now I'm shutting up. Please don't treat
Kelsey as an enemy (and vice versa). You're both too smart for that.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[CBFalconer]

Ian Collins wrote:

Kelsey Bjarnason wrote:

.... snip ...

>>
Unless you use them, at which point your code's portability has
gone straight into the crapper. Yay, C! Yesterday you were
portable across endless systems, now you're portable across...
well... who the hell knows, because all bets are off. An
absolute *leap* ahead, right into the 16th century.

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.

The problem, as I see it, is twofold. First, many 'programmers'
are using those fixed width types arbitrarily, without any need,
and thus making their code non-portable. Secondly, I don't really
see any reason for requiring them anywhere. At most the i/o path
to/from something is truncated to some fixed bit count. I may be
mistaken here.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>

--
Posted via a free Usenet account from http://www.teranews.com

[CBFalconer]

pete wrote:

Keith Thompson wrote:

>N1124 is the post-C99 draft you're referring to; it combines the
C99 standard with TC1 and TC2, with all differences from the

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

>official C99 marked by change bars.

What is N1124 a draft of?

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

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>

--
Posted via a free Usenet account from http://www.teranews.com

[Richard Heathfield]

CBFalconer said:

pete wrote:

>Keith Thompson wrote:

>>N1124 is the post-C99 draft you're referring to; it combines the
C99 standard with TC1 and TC2, with all differences from the

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

>>official C99 marked by change bars.

What is N1124 a draft of?

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

Keith's words (above) do not indicate what N1124 is a draft of. They
merely indicate that it is a draft, and give further information about
the origin of its contents.

To answer pete's question: Yet Another Dead Duck.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Ian Collins]

CBFalconer wrote:

>
The problem, as I see it, is twofold. First, many 'programmers'
are using those fixed width types arbitrarily, without any need,
and thus making their code non-portable.

Agreed.

Secondly, I don't really
see any reason for requiring them anywhere. At most the i/o path
to/from something is truncated to some fixed bit count. I may be
mistaken here.

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.

--
Ian Collins.

[Flash Gordon]

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

CBFalconer wrote:

>The problem, as I see it, is twofold. First, many 'programmers'
are using those fixed width types arbitrarily, without any need,
and thus making their code non-portable.

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.

>Secondly, I don't really
see any reason for requiring them anywhere. At most the i/o path
to/from something is truncated to some fixed bit count. I may be
mistaken here.

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.
--
Flash Gordon

[Flash Gordon]

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

On Thu, 13 Sep 2007 07:37:57 +1200, Ian Collins wrote:

>Kelsey Bjarnason wrote:

>>[snips]

On Wed, 12 Sep 2007 20:31:56 +1200, Ian Collins wrote:

If your code is processing a stream of say 16 bit data, you can either
assume the existence of a 16 (or 8) bit type
Like char and short? Oh, they're not required to be 8 and 16 bits, just
at least 8 and 16 bits. Meaning we've had perfectly good types for this
sort of thing since what, K&R?

So what would you rather have, code using short that compiles happily on
a system where short is 32 or 18 bits, but then fails to work (possibly
in a less than obvious way) or code that uses int16_t and won't compile?

I'd rather have code that compiles and works. Maybe that means masking,
fine, I can live with that if I have to.

Sometimes you would have to do a lot more than that, and you would be
doing it on a significant portion of the lines of code or doing a lot of
work to PROVE that you could get away without it.

Personally I prefer NOT to spend major effort on things which are
explicitly NOT a requirement.

At least I'd only have one code
path to maintain,

Those of us using uint16_t only have one code path because the code is
only required to work on platforms with a 16 bit unsigned integer type
without padding. We don't have to go through nests of conditional
compilation to mate it work.

Do you REALLY find so hard to understand that some code does not have to
be portable to every system? Will ALL of your code run on a system with
16 bit char, short and int with only 8K of space for the program and 8K
of space for data?

and it would work on _any_ conforming implementation.

So will ALL of your programs fit in to 8K of program space and 8K of
data space? I've spent a LOT of time programming for such systems,
although I don't now. However, back when I did the SW I wrote to process
live video definitely would NOT have fitted on such a small architecture
because it needed space for an entire frame of video, and it needed it
all in RAM for speed. Oh, and the processors on the small systems would
not be anywhere near fast enough. The code I currently work on requires
a few MB of program space, so also would not fit, and that is all code
REQUIRED to do the job.

NOW do you get that some code is not required to run on ANY conforming
implementations? Do you get that even YOU could not write code to solve
some problems that would run CORRECTLY on ANY conforming implementation?

We ALL accept restrictions in portability. It might be restricted to
only hosted implementations because it uses stdio. It might be
restricted to only implementations with more than the minimum of memory.
It might be restricted to only implementations with a networking (give
me a driver for a specific NIC that will work on a machine without ANY
NIC). Or it might be restricted to only implementations with a 16 bit
integer type with no risk of wanting it to run on a CRAY because you are
not going to get a CRAY installed in a fighter jet or a mobile phone.
--
Flash Gordon

[Chris Hills]

In article <46***************@yahoo.com>, CBFalconer
<cb********@yahoo.comwrites

>pete wrote:

>Keith Thompson wrote:

>>N1124 is the post-C99 draft you're referring to; it combines the
C99 standard with TC1 and TC2, with all differences from the

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

>>official C99 marked by change bars.

What is N1124 a draft of?

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

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

[Philip Potter]

Kelsey Bjarnason wrote:

[snips]

On Wed, 12 Sep 2007 20:31:56 +1200, Ian Collins wrote:

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

--
Philip Potter pgp <atdoc.ic.ac.uk

[Philip Potter]

Richard Heathfield wrote:

Flash Gordon said:

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

So you are allowed to ignore the portability issues that do not affect
you but those who have different portability requirements are not
allowed to limit themselves to the implementations of interest to you?

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.

--
Philip Potter pgp <atdoc.ic.ac.uk

[Richard Heathfield]

Chris Hills said:

<snip>

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?

<snip>

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 <http://www.cpax.org.uk>
Email: -www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Richard Heathfield]

Chris Hills said:

<snip>

C99 was not taken up by the industry.

Right. So why bother to argue about it?

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999