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.

[jacob navia]

Bob Timpkinson wrote:

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.

No way unless:
1) You download the source code of gcc
2) Change quite a few things inside

You would have to work for approx 6 months to 2 years depending
on your luck and knowledge about compilers

Just as a gcc user I see no way to do that.

But why you want that in the first place?

[Keith Thompson]

Bob Timpkinson <bo*@nospam.comwrites:

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

We don't know. Try asking in gnu.gcc.help.

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

[Mark McIntyre]

On Wed, 5 Sep 2007 09:18:00 +0200 (CEST), in comp.lang.c , Bob
Timpkinson <bo*@nospam.comwrote:

>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

Why would you want to?
Compilers are built to match the hardware / software environment
they're targetting.

--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

[Bob Timpkinson]

I don't believe that's true - surely any C compiler worth its salt will
allow you to set this sort of option?

It seems logical to me to give every integer size its own type, and then
you can program with confidence knowing how big each variable will be.

Bob.

On 5 Sep 2007 at 7:22, jacob navia wrote:

Bob Timpkinson wrote:

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

No way unless:
1) You download the source code of gcc
2) Change quite a few things inside

You would have to work for approx 6 months to 2 years depending
on your luck and knowledge about compilers

Just as a gcc user I see no way to do that.

But why you want that in the first place?

[jacob navia]

Bob Timpkinson wrote:

I don't believe that's true - surely any C compiler worth its salt will
allow you to set this sort of option?

It seems logical to me to give every integer size its own type, and then
you can program with confidence knowing how big each variable will be.

Bob.

I repeat:
There is NO C compiler that allows you to change the sizes of the
basic types. Period.

Please show me one C compiler that does that.

jacob

[Ben Pfaff]

Bob Timpkinson <bo*@nospam.comwrites:

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

gnu.gcc.help is a better place for this kind of question.
Followups set.

<OFF-TOPIC>
I don't think so. In particular, I don't think GCC has support
for quad-word 128-bit arithmetic, except for use with
processor-specific built-in functions for e.g. SSE support.
</OFF-TOPIC>
--
"I hope, some day, to learn to read.
It seems to be even harder than writing."
--Richard Heathfield

[Flash Gordon]

jacob navia wrote, On 05/09/07 20:17:

Bob Timpkinson wrote:

>I don't believe that's true - surely any C compiler worth its salt will
allow you to set this sort of option?

It seems logical to me to give every integer size its own type, and then
you can program with confidence knowing how big each variable will be.

I repeat:
There is NO C compiler that allows you to change the sizes of the
basic types. Period.

Please show me one C compiler that does that.

gcc 3.3.3
-m96bit-long-double/-m128-bit-long-double
-m32/-m64

Or then there are some of the old 80x86 compilers that allowed you to
select one of a number of sies for pointers.

Of course, you cannot select any values you want, and you can't select
what the OP wanted, but you *can* change them between allowed values.
--
Flash Gordon

[jacob navia]

Flash Gordon wrote:

jacob navia wrote, On 05/09/07 20:17:

>Bob Timpkinson wrote:

>>I don't believe that's true - surely any C compiler worth its salt will
allow you to set this sort of option?

It seems logical to me to give every integer size its own type, and then
you can program with confidence knowing how big each variable will be.

I repeat:
There is NO C compiler that allows you to change the sizes of the
basic types. Period.

Please show me one C compiler that does that.

gcc 3.3.3
-m96bit-long-double/-m128-bit-long-double
-m32/-m64

Or then there are some of the old 80x86 compilers that allowed you to
select one of a number of sies for pointers.

Of course, you cannot select any values you want, and you can't select
what the OP wanted, but you *can* change them between allowed values.

This is a completely different thing and you know it.

[Keith Thompson]

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

Bob Timpkinson wrote:

>I don't believe that's true - surely any C compiler worth its salt will
allow you to set this sort of option?
It seems logical to me to give every integer size its own type, and
then
you can program with confidence knowing how big each variable will be.

I repeat:
There is NO C compiler that allows you to change the sizes of the
basic types. Period.

Please show me one C compiler that does that.

You really should stop and think for a moment before making sweeping
statements like that.

Here's the source file "c.c" that I use for all three tests:
#include <stdio.h>
int main(void)
{
printf("sizeof(long) = %d\n", (int)sizeof(long));
return 0;
}

On SPARC Solaris 9:
================================
% cc -V
cc: Sun C 5.5 Patch 112760-18 2005/06/14
usage: cc [ options] files. Use 'cc -flags' for details
% cc c.c -o c && ./c
sizeof(long) = 4
% cc -xtarget=ultra -xarch=v9 c.c -o c && ./c
sizeof(long) = 8
================================

On Fedora x86-64:
================================
% gcc --version | head -1
gcc (GCC) 4.1.2 20070626 (Red Hat 4.1.2-13)
% gcc -m32 c.c -o c && ./c
sizeof(long) = 4
% gcc -m64 c.c -o c && ./c
sizeof(long) = 8
================================

On AIX PowerPC:
================================
% xlc -qversion
IBM XL C/C++ Enterprise Edition V8.0 for AIX
Version: 08.00.0000.0011
% xlc -q32 c.c -o c && ./c
sizeof(long) = 4
% xlc -q64 c.c -o c && ./c
sizeof(long) = 8
================================

I don't know of any compilers that allow you to specify the sizes of
*all* the predefined integer types.

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

[Flash Gordon]

jacob navia wrote, On 05/09/07 20:43:

Flash Gordon wrote:

>jacob navia wrote, On 05/09/07 20:17:

>>Bob Timpkinson wrote:
I don't believe that's true - surely any C compiler worth its salt will
allow you to set this sort of option?

It seems logical to me to give every integer size its own type, and
then
you can program with confidence knowing how big each variable will be.

I repeat:
There is NO C compiler that allows you to change the sizes of the
basic types. Period.

Please show me one C compiler that does that.

gcc 3.3.3
-m96bit-long-double/-m128-bit-long-double
-m32/-m64

Or then there are some of the old 80x86 compilers that allowed you to
select one of a number of sies for pointers.

Of course, you cannot select any values you want, and you can't select
what the OP wanted, but you *can* change them between allowed values.

This is a completely different thing and you know it.

It is changing the sizes of basic types, something you said was
categorically not provided by any compiler. It is doing it without
switching to a different platform or OS. If you state something as an
absolute, you should expect people to call you on it.

For another processor gcc has the option to make int 16 bits. For yet
another you can select whether int is 32 or 64 bits.

The simple fact is that you were wrong to say that no compilers allow
you to change the size of basic types, and even more wrong to be so
emphatic about it, because some do for some targets.
--
Flash Gordon

[Keith Thompson]

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

Flash Gordon wrote:

>jacob navia wrote, On 05/09/07 20:17:

>>Bob Timpkinson wrote:
I don't believe that's true - surely any C compiler worth its salt will
allow you to set this sort of option?

It seems logical to me to give every integer size its own type, and then
you can program with confidence knowing how big each variable will be.

I repeat:
There is NO C compiler that allows you to change the sizes of the
basic types. Period.

Please show me one C compiler that does that.

gcc 3.3.3
-m96bit-long-double/-m128-bit-long-double
-m32/-m64
Or then there are some of the old 80x86 compilers that allowed you
to select one of a number of sies for pointers.
Of course, you cannot select any values you want, and you can't
select what the OP wanted, but you *can* change them between allowed
values.

This is a completely different thing and you know it.

It's different from what you probably meant. It's exactly the same as
what you said:

There is NO C compiler that allows you to change the sizes of the
basic types. Period.

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

[Mark McIntyre]

On Wed, 5 Sep 2007 21:13:29 +0200 (CEST), in comp.lang.c , Bob
Timpkinson <bo*@nospam.comwrote:

>I don't believe that's true - surely any C compiler worth its salt will
allow you to set this sort of option?

Why?

>It seems logical to me to give every integer size its own type,

You'd better add in 7,9,18,36 and the other bitsizes then, there's
_lots_ of integer sizes out there in the wide world.....

>and then
you can program with confidence knowing how big each variable will be.

For a given implementation, you /do/ know. If you're writing code that
really really depends on the sizes, you probably either have an
algorithm error, or you're doing something hardware specific anyway.

--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

[Richard Tobin]

In article <sl********************@nospam.invalid>,
Bob Timpkinson <bo*@nospam.comwrote:

>I don't believe that's true - surely any C compiler worth its salt will
allow you to set this sort of option?

>It seems logical to me to give every integer size its own type, and then
you can program with confidence knowing how big each variable will be.

And how are you going to call the system libraries, which assume the
usual sizes? You can probably rebuild gcc to use different sizes, but
doing it on the fly is not worth it.

It would be easier to typedef all your integer types in terms of n-bit
types, or if you really want to you could use macros and define them
on the command line.

-- Richard
--
"Consideration shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.

[Gordon Burditt]

>I don't believe that's true - surely any C compiler worth its salt will

>allow you to set this sort of option?

Surely not (although some compilers give you a limited choice with
"memory models"). Can you imagine the number of different C libraries
you would need for all the possible different combinations of data
type sizes?

>It seems logical to me to give every integer size its own type, and then
you can program with confidence knowing how big each variable will be.

It seems logical to me that you cannot know what version of what compiler
will be used by someone else to compile the code.

There are a number of people who "know" (incorrectly) things like
sizeof(int) == sizeof(int *), sizeof(int) == sizeof(long), and
sizeof(int) == 4.

[Eric Sosman]

jacob navia wrote:

Bob Timpkinson wrote:

>I don't believe that's true - surely any C compiler worth its salt will
allow you to set this sort of option?

It seems logical to me to give every integer size its own type, and then
you can program with confidence knowing how big each variable will be.

Bob.

I repeat:
There is NO C compiler that allows you to change the sizes of the
basic types. Period.

Please show me one C compiler that does that.

Sun Studio 12. Also 11, 10, 9, and their Forte forbears.

--
Eric Sosman
es*****@ieee-dot-org.invalid

[karthikbalaguru]

jacob navia wrote:

Bob Timpkinson wrote:

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.

No way unless:
1) You download the source code of gcc
2) Change quite a few things inside

Interesting stuff. :) I have the source code of gcc.
What are the things that can possibly be changed to acheive this ?
Let me know your ideas . I have thought of giving that a try :):)

Thx in advans,
Karthik Balaguru

[Keith Thompson]

karthikbalaguru <ka***************@gmail.comwrites:

jacob navia wrote:

>Bob Timpkinson wrote:

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

No way unless:
1) You download the source code of gcc
2) Change quite a few things inside

Interesting stuff. :) I have the source code of gcc.
What are the things that can possibly be changed to acheive this ?
Let me know your ideas . I have thought of giving that a try :):)

You'll get more and better information in gnu.gcc.help.

But first, consider why you want to do this, and whether another
approach might meet your needs.

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

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

[Kelsey Bjarnason]

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

[Flash Gordon]

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

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

The relevant section is 1.18.1.1 para 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 de�ne the corresponding
typedef names.

So if it has a type matching the requirements it has to provide the
relevant typedef.

Personally I think it would be better if it required providing the
[u]intN_t types for all values of N for which it has a type with no
padding bits (and two's complement for the signed versions). I can't see
that it would be much work for the implementer.
--
Flash Gordon

[CBFalconer]

Flash Gordon wrote:

>

.... snip ...

>
Personally I think it would be better if it required providing the
[u]intN_t types for all values of N for which it has a type with
no padding bits (and two's complement for the signed versions). I
can't see that it would be much work for the implementer.

Ugh. You don't really want to hear my opinion about those useless
non-portable foolishnesses.

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

CBFalconer <cb********@yahoo.comwrote:

Flash Gordon wrote:

Personally I think it would be better if it required providing the
[u]intN_t types for all values of N for which it has a type with
no padding bits (and two's complement for the signed versions). I
can't see that it would be much work for the implementer.

Ugh. You don't really want to hear my opinion about those useless
non-portable foolishnesses.

Their unportability is, in this case, a feature. Suppose that you want
an exactly 32-bit unsigned type, for example to agree with a file
format. If your C99 implementation has a type of the kind you want, you
can rely on uint32_t being there. If uint32_t is not available, that
implementation is simply never going to give you what you want. In C90,
you'd have to put that kind of type behind conditional compilation
#ifdefs, one for each platform you want, _and_ hope that your compiler
never introduces padding bits behind your back; or you have to surround
every use of your type with &0xFFFFFFFF and so on. In C99, all you have
to do is check whether your compiler complains about uint32_t not
existing.

Richard

[Kelsey Bjarnason]

[snips]

On Tue, 11 Sep 2007 12:08:08 +0000, Richard Bos wrote:

Their unportability is, in this case, a feature. Suppose that you want
an exactly 32-bit unsigned type, for example to agree with a file
format. If your C99 implementation has a type of the kind you want, you
can rely on uint32_t being there. If uint32_t is not available, that
implementation is simply never going to give you what you want.

No, but if I were to use, say, an unsigned long I'd know I was using an
unsigned type at least 32 bits long, and more importantly, I'd know the
type was going to exist, period.

So now I use a uint32_t and my code fails on compiler X because the type
simply does not exist.

My options now are twofold: introduce an additional complexity, via ifdefs
and the like, such that on compiler X it uses unsigned long and a lot of
masking, where on compiler Y it uses uint32_t, or I can do the sensible
thing: skip uint32_t entirely and just write the code using standard types
so that it will work anywhere.

At which point, of course, the new integer types become instantly
irrelevant - so why have them?

In C90,
you'd have to put that kind of type behind conditional compilation
#ifdefs, one for each platform you want, _and_ hope that your compiler
never introduces padding bits behind your back; or you have to surround
every use of your type with &0xFFFFFFFF and so on. In C99, all you have
to do is check whether your compiler complains about uint32_t not
existing.

No, not "check whether your compiler complains". You have to write the
code such that it works, correctly, _regardless_ of the compiler - this is
the point to writing portable code, that you don't _care_ what compiler it
is built with, modulo a few minor exceptions (eg requiring a minimum
32-bit implementation).

The fact you cannot do this while using uint32_t et al unless you also
include code to support those implementations which don't have them
increases code complexity for no benefit; the old types and masking, etc,
will work just as well on both so if you have to write that anyway, why
add more code to do the exact same job using the new types?

The new types would be great if you could rely on them. You can't. Since
you can't, they're no more benefit than if they didn't exist at all.

[Stephen Sprunk]

"Kelsey Bjarnason" <kb********@gmail.comwrote in message
news:lk************@spanky.localhost.net...

On Tue, 11 Sep 2007 12:08:08 +0000, Richard Bos wrote:

>In C90, you'd have to put that kind of type behind conditional
compilation
#ifdefs, one for each platform you want, _and_ hope that your compiler
never introduces padding bits behind your back; or you have to surround
every use of your type with &0xFFFFFFFF and so on. In C99, all you have
to do is check whether your compiler complains about uint32_t not
existing.

No, not "check whether your compiler complains". You have to write the
code such that it works, correctly, _regardless_ of the compiler - this is
the point to writing portable code, that you don't _care_ what compiler it
is built with, modulo a few minor exceptions (eg requiring a minimum
32-bit implementation).

The fact you cannot do this while using uint32_t et al unless you also
include code to support those implementations which don't have them
increases code complexity for no benefit; the old types and masking, etc,
will work just as well on both so if you have to write that anyway, why
add more code to do the exact same job using the new types?

This newsgroup notwithstanding, the reality is that there are a lot of
people that choose to write "unportable" code for various purposes. Those
purposes may, for instance, may only include situations where a 32-bit type
is mandatory and a system that provides only 24- and 48-bit (or 36-bit)
types will never be targeted because the code has no purpose _ever_ being
used on those machines. Or the programmer (or her management) may simply
decide that supporting other machines is irrelevant, but code should still
be portable to "common" systems.

Such code is not portable in the purest sense of the word, but "portable to
all 32-bit and 64-bit systems" is sufficient for a lot of code. For
instance, you may have a PCI device you're writing drivers for, and being
portable to every architecture that has PCI implementations is all that
matters. Who cares whether the code runs on a PDP-8 if PCI isn't available
there?

(I'm sure the DS9k will acquire PCI support as a result of this message, and
someone will explain how to cleanly write drivers that will be perfectly
portable to it despite having some oddball number of bits in an int/long,
but come on, folks, this is far past the point where anyone can defend
requiring 100% portable code.)

S

--
Stephen Sprunk "God does not play dice." --Albert Einstein
CCIE #3723 "God is an inveterate gambler, and He throws the
K5SSS dice at every possible opportunity." --Stephen Hawking
--
Posted via a free Usenet account from http://www.teranews.com

[Keith Thompson]

rl*@hoekstra-uitgeverij.nl (Richard Bos) writes:

CBFalconer <cb********@yahoo.comwrote:

>Flash Gordon wrote:

Personally I think it would be better if it required providing the
[u]intN_t types for all values of N for which it has a type with
no padding bits (and two's complement for the signed versions). I
can't see that it would be much work for the implementer.

Ugh. You don't really want to hear my opinion about those useless
non-portable foolishnesses.

Their unportability is, in this case, a feature. Suppose that you want
an exactly 32-bit unsigned type, for example to agree with a file
format. If your C99 implementation has a type of the kind you want, you
can rely on uint32_t being there. If uint32_t is not available, that
implementation is simply never going to give you what you want. In C90,
you'd have to put that kind of type behind conditional compilation
#ifdefs, one for each platform you want, _and_ hope that your compiler
never introduces padding bits behind your back; or you have to surround
every use of your type with &0xFFFFFFFF and so on. In C99, all you have
to do is check whether your compiler complains about uint32_t not
existing.

All you have to do is;

#include <stdint.h>
#ifdef UINT32_MAX
/* uint32_t exists */
#else
/* uint32_t doesn't exist */
#endif

What to do if UINT32_MAX isn't defined depends on the application. If
you don't care about supporting implementations that don't have a
32-bit unsigned integer type, you can use #error to abort the
compilation with whatever error message you like. If you do care
about such implementations, you have some more work to do.

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

[Al Balmer]

On Tue, 11 Sep 2007 08:59:49 -0700, Kelsey Bjarnason
<kb********@gmail.comwrote:

>[snips]

On Tue, 11 Sep 2007 12:08:08 +0000, Richard Bos wrote:

>Their unportability is, in this case, a feature. Suppose that you want
an exactly 32-bit unsigned type, for example to agree with a file
format. If your C99 implementation has a type of the kind you want, you
can rely on uint32_t being there. If uint32_t is not available, that
implementation is simply never going to give you what you want.

No, but if I were to use, say, an unsigned long I'd know I was using an
unsigned type at least 32 bits long, and more importantly, I'd know the
type was going to exist, period.

So now I use a uint32_t and my code fails on compiler X because the type
simply does not exist.

Then, neither does the 32-bit unsigned long. If your requirement is
for a type *at least* 32 bits, rather than exactly 32 bits, you would
use int_least32_t.

--
Al Balmer
Sun City, AZ

[Keith Thompson]

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

[snips]

On Tue, 11 Sep 2007 12:08:08 +0000, Richard Bos wrote:

>Their unportability is, in this case, a feature. Suppose that you want
an exactly 32-bit unsigned type, for example to agree with a file
format. If your C99 implementation has a type of the kind you want, you
can rely on uint32_t being there. If uint32_t is not available, that
implementation is simply never going to give you what you want.

No, but if I were to use, say, an unsigned long I'd know I was using an
unsigned type at least 32 bits long, and more importantly, I'd know the
type was going to exist, period.

So now I use a uint32_t and my code fails on compiler X because the type
simply does not exist.

Then you shouldn't have used uint32_t.

If you want the smallest unsigned type that's at least 32 bits, you
can use uint_least32_t. If you want the "fastest" unsigned type
that's at least 32 bits, you can use uint_fast32_t. Both are required
to exist -- assuming, of course, that you have either a C99
implementation or a pre-c99 implementation that supports <stdint.h>.

Of course you can just use unsigned long, which is guaranteed to be at
least 32 bits. But if, for example, int is 32 bits and long is 64
bits, and operations on int are faster than operations on long, then
you're wasting both time and space.

My options now are twofold: introduce an additional complexity, via ifdefs
and the like, such that on compiler X it uses unsigned long and a lot of
masking, where on compiler Y it uses uint32_t, or I can do the sensible
thing: skip uint32_t entirely and just write the code using standard types
so that it will work anywhere.

At which point, of course, the new integer types become instantly
irrelevant - so why have them?

The purpose of the exact-width types is to support non-portable code.
If you need to write 100% portable code, don't use them.

[...]

No, not "check whether your compiler complains". You have to write the
code such that it works, correctly, _regardless_ of the compiler - this is
the point to writing portable code, that you don't _care_ what compiler it
is built with, modulo a few minor exceptions (eg requiring a minimum
32-bit implementation).

No, you don't *have* to write code that works corretly regardless of
the compiler. Sometimes it's sufficient to write code that works
correctly for the implementations you care about, and cleanly fails
compilation for implementations where it won't work.

[...]

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

[Kelsey Bjarnason]

[snips]

On Tue, 11 Sep 2007 13:17:49 -0500, Stephen Sprunk wrote:

>The fact you cannot do this while using uint32_t et al unless you also
include code to support those implementations which don't have them
increases code complexity for no benefit; the old types and masking, etc,
will work just as well on both so if you have to write that anyway, why
add more code to do the exact same job using the new types?

This newsgroup notwithstanding, the reality is that there are a lot of
people that choose to write "unportable" code for various purposes.

Sure, I've done so myself. And when doing so, I'll happily use the fact
that on implementation X, char is 8 bits, int 16, long 32 or what have you
and not need those pesky int32_t things at all.

Remember, they have to exist _if_ the implementation already has such
types, meaning that if they exist, you *already* have perfectly
functional, though non-portable, options, making the int types completely
irrelevant.

Those purposes may, for instance, may only include situations where a
32-bit type is mandatory and a system that provides only 24- and 48-bit
(or 36-bit) types will never be targeted because the code has no purpose
_ever_ being used on those machines.

Possibly, but then again, who are you to say whether the code belongs on
a different architecture - unless you're doing something
architecture-specific.

Or the programmer (or her
management) may simply decide that supporting other machines is
irrelevant, but code should still be portable to "common" systems.

And 640K is enough for anybody. Write the code right, you don't care if
it's run on a 48 bit machine.

Such code is not portable in the purest sense of the word, but "portable
to all 32-bit and 64-bit systems" is sufficient for a lot of code.

And you cannot rely on inttypes on those, as a device which uses 32-bit
types for all is a 32-bit system, but not one providing, oh, a uint8_t
equivalent type, meaning you cannot rely on the inttypes being useful even
on "32 and 64 bit systems", whereas you *can* write code that works on
them... which means once again, the int types are useless.

[Kelsey Bjarnason]

On Tue, 11 Sep 2007 20:17:32 +0000, Al Balmer wrote:

On Tue, 11 Sep 2007 08:59:49 -0700, Kelsey Bjarnason
<kb********@gmail.comwrote:

>>[snips]

On Tue, 11 Sep 2007 12:08:08 +0000, Richard Bos wrote:

>>Their unportability is, in this case, a feature. Suppose that you want
an exactly 32-bit unsigned type, for example to agree with a file
format. If your C99 implementation has a type of the kind you want, you
can rely on uint32_t being there. If uint32_t is not available, that
implementation is simply never going to give you what you want.

No, but if I were to use, say, an unsigned long I'd know I was using an
unsigned type at least 32 bits long, and more importantly, I'd know the
type was going to exist, period.

So now I use a uint32_t and my code fails on compiler X because the type
simply does not exist.

Then, neither does the 32-bit unsigned long. If your requirement is
for a type *at least* 32 bits, rather than exactly 32 bits, you would
use int_least32_t.

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

Exactly the same set (apart from the addition of long long). So why have
the new int types? You can't rely on them being there, you can't write
portable code with them.

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.

Stuff like that should be mandated or abolished; left in limbo it detracts
from the language instead of adding to it.

[Kelsey Bjarnason]

[snips]

On Tue, 11 Sep 2007 13:24:39 -0700, Keith Thompson wrote:

>So now I use a uint32_t and my code fails on compiler X because the type
simply does not exist.

Then you shouldn't have used uint32_t.

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

Oh, right, because an implementation *may* have it. Or it may not. Does
it? Your guess is as good as mine - but if I'm writing code intended to
be portable, I can't afford to guess, but I can't tell what compiler might
be used, either.

Simple solution: use types that work. char, short, int, long. Relying on
this half-baked nonsense of types that a conforming implementation can get
away with not including at all is ridiculous.

The purpose of the exact-width types is to support non-portable code. If
you need to write 100% portable code, don't use them.

Lots of things can be made more efficient with known sizes. Except you
can't do that because the types you could use to pull this off can't be
relied on to even exist. As to non-portable code, the new types, as I
read it, only need to exist _if_ the implementation _already_ has existing
equivalent-sized types... so you don't need the new types for this; they
buy nothing.

No, you don't *have* to write code that works corretly regardless of the
compiler.

True; I could write code that needs to be rewritten every time one changes
compilers. Doing so, however, would be costly and pointless. I like to
write things as portably as possible, which is one reason I like C. The
new int types could have been something of a boon in this regard; instead
they're more of a boondoggle. Completely devoid of any value, as far as I
can see.

You could convince me there might be some redeeming value, but you're
going to have to do better than "non-portable code" to pull it off, as
these types are required to exist only where existing types of the right
size exist, AIUI... meaning your non-portable code *already* has the
option to make non-portable use of type sizes, meaning you don't need the
new int types, meaning they're not justified for that purpose... but then,
they can't be relied upon to even exist for other purposes, so convincing
me is going to require showing how you can write code which is neither
portable nor non-portable, that makes use of them in a manner in which
existing types cannot be used.

I don't think it can be done... but then, I'm not the one suggesting these
things have a justification for existing in the first place.

[Stephen Sprunk]

"Kelsey Bjarnason" <kb********@gmail.comwrote in message
news:7t************@spanky.localhost.net...

On Tue, 11 Sep 2007 13:24:39 -0700, Keith Thompson wrote:

>The purpose of the exact-width types is to support non-portable code. If
you need to write 100% portable code, don't use them.

Lots of things can be made more efficient with known sizes. Except you
can't do that because the types you could use to pull this off can't be
relied on to even exist. As to non-portable code, the new types, as I
read it, only need to exist _if_ the implementation _already_ has existing
equivalent-sized types... so you don't need the new types for this; they
buy nothing.

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. 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. Pre-stdint, I had to use a bunch of preprocessor
hacks to typedef a "u32" or error out; now I can just #include <stdint.h>,
declare a variable as uint32_t, and if the code compiles I know I got
exactly what I wanted.

S

--
Stephen Sprunk "God does not play dice." --Albert Einstein
CCIE #3723 "God is an inveterate gambler, and He throws the
K5SSS dice at every possible opportunity." --Stephen Hawking
--
Posted via a free Usenet account from http://www.teranews.com

[Keith Thompson]

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

[snips]

On Tue, 11 Sep 2007 13:24:39 -0700, Keith Thompson wrote:

>>So now I use a uint32_t and my code fails on compiler X because the type
simply does not exist.

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. Maybe it's a 64-bit system with
8-bit bytes and 64-bit shorts (I've used such systems). Maybe it's a
system with 9-bit bytes.

Oh, right, because an implementation *may* have it. Or it may not. Does
it? Your guess is as good as mine - but if I'm writing code intended to
be portable, I can't afford to guess, but I can't tell what compiler might
be used, either.

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

Simple solution: use types that work. char, short, int, long. Relying on
this half-baked nonsense of types that a conforming implementation can get
away with not including at all is ridiculous.

>The purpose of the exact-width types is to support non-portable code. If
you need to write 100% portable code, don't use them.

Lots of things can be made more efficient with known sizes. Except you
can't do that because the types you could use to pull this off can't be
relied on to even exist. As to non-portable code, the new types, as I
read it, only need to exist _if_ the implementation _already_ has existing
equivalent-sized types... so you don't need the new types for this; they
buy nothing.

The give you *names* for types of specified widths. (That's all
typedefs do.)

>No, you don't *have* to write code that works corretly regardless of the
compiler.

True; I could write code that needs to be rewritten every time one changes
compilers. Doing so, however, would be costly and pointless. I like to
write things as portably as possible, which is one reason I like C. The
new int types could have been something of a boon in this regard; instead
they're more of a boondoggle. Completely devoid of any value, as far as I
can see.

Or you can write code that has requirements that can be met on some,
but not all, implementations, and you can use things like int32_t both
to meet those requirements where it's possible, and to indicate (by a
compilation failure) when it's not.

In another article in this thread, you wrote:
| Sure, I've done so myself. And when doing so, I'll happily use the fact
| that on implementation X, char is 8 bits, int 16, long 32 or what have you
| and not need those pesky int32_t things at all.

Suppose you have an externally imposed requirement for an unsigned
integer type that's exactly 32 bits. Assume three implementations:

System X: int is 16 bits, long is 32 bits
System Y: int is 32 bits, long is 64 bits
System Z: int is 18 bits, long is 36 bits

You can use 'unsigned long', and your program will work only on System
X. Or you can use 'unsigned int', and your program will work only on
System Y. Or you can use 'uint32_t', and your program will work on
*both* System X and System Y.

(Or you can use your own typedef, defined as unsigned long on System X
and unigned int on System Y, but why bother with the authors of
<stdint.hhave already done it for you?)

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, or
you do the hard work of emulating 32-bit integers on systems that
don't directly support them. Portability is not a simple binary
state. <stdint.hcan help in writing software that's more portable
that it otherwise would be, without necessarily being 100% portable.
(Assuming, as always, that the implementation provides <stdint.h>.)

In my opinion, making the exact-width types the "default" (i.e., the
types with the most obvious names) was a poor choice. I would have
preferred the optional exact-width 32-bit unsigned type to be called
uint_exact32_t. With the current naming scheme, it's too tempting to
use exact-width types when what's really needed is a "least" or "fast"
type.

But the exact-width types can be useful in some contexts.

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

[Al Balmer]

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.

--
Al Balmer
Sun City, AZ

[Kelsey Bjarnason]

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.

[Kelsey Bjarnason]

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

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.

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?

[Kelsey Bjarnason]

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

Now if that code could actually rely upon the new int types existing, then
it could opt to use them, with the realization that there will be, on some
systems, some overhead in using some of the types, but trading that off
against the inefficiencies of massively increased storage requirements
(or, worse, massively reducing the amount of effective storage used).

Can't do it, though, because those types don't exist. Or, rather, they
do, for compiler X but not Y. Maybe. If it's a Thursday and sufficient
dead chickens have been waved.

>equivalent-sized types... so you don't need the new types for this; they
buy nothing.

The give you *names* for types of specified widths. (That's all
typedefs do.)

Yeah, and you can't rely on 'em, so you have to get all intimate with the
implementation anyways so your code gives up any hope of being portable so
you may as well use the types which _do_ exist. Again, these things buy
nothing.

Or you can write code that has requirements that can be met on some,
but not all, implementations, and you can use things like int32_t both
to meet those requirements where it's possible, and to indicate (by a
compilation failure) when it's not.

Sure. Now how about a case where you'd need to do this? I gave an
example of where having known sized types is beneficial, but lacking them
isn't fatal. How about you give us an example where lacking known sized
types is fatal, but you don't know and can't restrict the used
implementations?

That is, show us a case where you absolutely have to have 32-bit ints,
say, but cannot know and cannot restrict the code to implementations which
support a 32-bit int.

Oh, but wait... if you *can* do this, then you don't need the new int
types anyhow, because the size of a plain old int works just fine and you
don't need these newfangled monstrosities.

(Or you can use your own typedef, defined as unsigned long on System X
and unigned int on System Y, but why bother with the authors of
<stdint.hhave already done it for you?)

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

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? Hey, my C compiler only works if you have a
Token Ring adapter installed! Makes bugger all sense. There's enough
limits and hassles in writing portable code already, without going out of
your way to add on extra limits which don't buy anything.

[Ian Collins]

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.

--
Ian Collins.

[Ian Collins]

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.

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.

Nonsense, I wouldn't call PPC or SPARC "close equivalents" to x86.

>

> 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 your code requires exact size types that can't be defined for a
particular system, it can't be run on that system without rework,
whether the typedefs exist or not.

--
Ian Collins.

[Richard Heathfield]

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.

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

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.

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

Sometimes you do have to either rely on a fixed size, or go through a
more convoluted process to work round the possibility of that size not
being available.

--
Ian Collins.

[Richard Heathfield]

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

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.

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.

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

>
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, it has always
been an issue. All C99 does is provide a standardised set of names.

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.

--
Ian Collins.

[Charlie Gordon]

"Al Balmer" <al******@att.neta écrit dans le message de news:
dk********************************@4ax.com...

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.

More precisely, int32_t is guaranteed to use 2's complement and no padding
with exactly 32 bits. Such is not the case of int_least32_t that can use
another arithmetic model. The minimal range of values supported by
int_least32_t is not superset of that of int32_t, which is fixed and
specified.

int32_t warrants exact size _and_ arithmetic model.

--
Chqrlie.

PS: I would vote for eradication of obsolete non 2's complement stuff from
the Standard and simplify at least this issue.

[Richard Heathfield]

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.

it has always been an issue.

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

All C99 does is provide a standardised set of names.

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

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.

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

[Philip Potter]

Kelsey Bjarnason wrote:

[snips]

On Tue, 11 Sep 2007 13:17:49 -0500, Stephen Sprunk wrote:

>>The fact you cannot do this while using uint32_t et al unless you also
include code to support those implementations which don't have them
increases code complexity for no benefit; the old types and masking, etc,
will work just as well on both so if you have to write that anyway, why
add more code to do the exact same job using the new types?

>This newsgroup notwithstanding, the reality is that there are a lot of
people that choose to write "unportable" code for various purposes.

Sure, I've done so myself. And when doing so, I'll happily use the fact
that on implementation X, char is 8 bits, int 16, long 32 or what have you
and not need those pesky int32_t things at all.

Remember, they have to exist _if_ the implementation already has such
types, meaning that if they exist, you *already* have perfectly
functional, though non-portable, options, making the int types completely
irrelevant.

Consider the following two implementations:

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

Both implementations have a 32-bit integer type, but they're called different
things. Using int32_t does all the pesky #ifdefing for you.

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

[Army1987]

On Mon, 10 Sep 2007 18:44:16 +0100, Flash Gordon wrote:

Personally I think it would be better if it required providing the
[u]intN_t types for all values of N for which it has a type with no
padding bits (and two's complement for the signed versions). I can't see
that it would be much work for the implementer.

Such a requirement has been added in n1124:
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 de�ne the corresponding typedef names.

--
Army1987 (Replace "NOSPAM" with "email")
If you're sending e-mail from a Windows machine, turn off Microsoft's
stupid “Smart Quotes� feature. This is so you'll avoid sprinkling garbage
characters through your mail. -- Eric S. Raymond and Rick Moen

[Army1987]

On Tue, 11 Sep 2007 12:08:08 +0000, Richard Bos wrote:

Their unportability is, in this case, a feature. Suppose that you want
an exactly 32-bit unsigned type, for example to agree with a file
format.

How do you know that your type has the same endianness as the file
format?

If your C99 implementation has a type of the kind you want, you
can rely on uint32_t being there. If uint32_t is not available, that
implementation is simply never going to give you what you want. In C90,
you'd have to put that kind of type behind conditional compilation
#ifdefs, one for each platform you want, _and_ hope that your compiler
never introduces padding bits behind your back; or you have to surround
every use of your type with &0xFFFFFFFF and so on. In C99, all you have
to do is check whether your compiler complains about uint32_t not
existing.

(Or more sanely
#ifndef UINT32_MAX
#error something
#endif
)
--
Army1987 (Replace "NOSPAM" with "email")
If you're sending e-mail from a Windows machine, turn off Microsoft's
stupid “Smart Quotes� feature. This is so you'll avoid sprinkling garbage
characters through your mail. -- Eric S. Raymond and Rick Moen

[Richard Bos]

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

On Tue, 11 Sep 2007 20:17:32 +0000, Al Balmer wrote:

On Tue, 11 Sep 2007 08:59:49 -0700, Kelsey Bjarnason
<kb********@gmail.comwrote:

>[snips]

On Tue, 11 Sep 2007 12:08:08 +0000, Richard Bos wrote:

Their unportability is, in this case, a feature. Suppose that you want
an exactly 32-bit unsigned type, for example to agree with a file
format. If your C99 implementation has a type of the kind you want, you
can rely on uint32_t being there. If uint32_t is not available, that
implementation is simply never going to give you what you want.

No, but if I were to use, say, an unsigned long I'd know I was using an
unsigned type at least 32 bits long, and more importantly, I'd know the
type was going to exist, period.

So now I use a uint32_t and my code fails on compiler X because the type
simply does not exist.

Then, neither does the 32-bit unsigned long. If your requirement is
for a type *at least* 32 bits, rather than exactly 32 bits, you would
use int_least32_t.

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?

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.

Richard

[Chris Hills]

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.
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

[Richard Bos]

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

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.

In which case, the program you want can't be easily written for that
platform anyway. So instead of hacking your way around with bitwise
operations and getting files that may or may not work depending on your
file transfer settings, you accept that you don't want to use that
platform. _Or_ you choose the pain. But at least you're pre-warned.

Richard