Best Multi-Platform Way to Define Standard Types Such as UINT32

[David T. Ashley]

I'm writing code which will compile on multiple Windows and multiple *nix
platforms. Some will have 64-bit integers, I believe.

What is my best option to define platform-independent types such as UINT32
or UINT64? I'm not sure how to sort out the various platforms and integer
sizes, and some of it may even vary based on compiler options.

Thanks

 

[Ian Collins]

I'm writing code which will compile on multiple Windows and multiple *nix
platforms. Some will have 64-bit integers, I believe.

What is my best option to define platform-independent types such as UINT32
or UINT64? I'm not sure how to sort out the various platforms and integer
sizes, and some of it may even vary based on compiler options.

Probably a good place to start would be <stdint.h> on one of the 64 bit
capable systems. I think you should use the standard types, rather than
redefining them in caps.

 

[David T. Ashley]

Probably a good place to start would be <stdint.h> on one of the 64 bit
capable systems. I think you should use the standard types, rather than
redefining them in caps.

Thanks for that info. I looked up this file (<stdint.h>) on my Linux box,
and it is just what I was looking for.

However, I also have Microsoft Visual C++. I couldn't find <stdint.h> in
the include directory, so just to be sure I wasn't missing something, I
searched Microsoft's site by "stdint.h" and got no matches.

I think the Microsoft tool chain doesn't have such a file. It isn't clear
what to do, because even Windows will run on some 64-bit platforms.

Suggestions?

Dave.

 

[jacob navia]

David T. Ashley a écrit :

Thanks for that info. I looked up this file (<stdint.h>) on my Linux box,
and it is just what I was looking for.

However, I also have Microsoft Visual C++. I couldn't find <stdint.h> in
the include directory, so just to be sure I wasn't missing something, I
searched Microsoft's site by "stdint.h" and got no matches.

I think the Microsoft tool chain doesn't have such a file. It isn't clear
what to do, because even Windows will run on some 64-bit platforms.

Suggestions?

Dave.

Yes. Just copy your linux stdint.h to your Microsoft installation...

NOT very difficult. stdint.h is standard C. Microsoft dpesn't always
comply with it but this is easy to follow.

Of course you should remember that in 64 bit microsoft environment,
long is 32 bits and under 64 bit linux it is 64 bits. The file would
need at most a small editing change.

 

[Nelu]

I'm writing code which will compile on multiple Windows and multiple *nix
platforms. Some will have 64-bit integers, I believe.

There are standard types defined in stdint.h, although the header is
available only in C99: uint32/64_t and uint_least32/64_t

 

[Ian Collins]

David T. Ashley a écrit :

Yes. Just copy your linux stdint.h to your Microsoft installation...

NOT very difficult. stdint.h is standard C. Microsoft dpesn't always
comply with it but this is easy to follow.

Of course you should remember that in 64 bit microsoft environment,
long is 32 bits and under 64 bit linux it is 64 bits. The file would
need at most a small editing change.

Although not standardised, _LLP64 (windows) and _LP64 (just about
everyone else) macros can and often are used to define the memory model
used on 64 bit platforms.

 

[Ulrich Eckhardt]

I looked up this file (<stdint.h>) on my Linux
box, and it is just what I was looking for.

However, I also have Microsoft Visual C++. I couldn't find <stdint.h> in
the include directory, so just to be sure I wasn't missing something, I
searched Microsoft's site by "stdint.h" and got no matches.

Take a look at Boost[1]. While it's mainly a C++ library, it also has a
compatibility module for platforms lacking explicitly sized integers. If
it doesn't already work for C, you will probably be able to easily make it
work.

One thing though, which wasn't brought up yet: it is best to avoid such
types. Depending on the context, it might be necessary though.

Uli

[1] www.boost.org

 

[Ian Collins]

I looked up this file (<stdint.h>) on my Linux
box, and it is just what I was looking for.

However, I also have Microsoft Visual C++. I couldn't find <stdint.h> in
the include directory, so just to be sure I wasn't missing something, I
searched Microsoft's site by "stdint.h" and got no matches.

Take a look at Boost[1]. While it's mainly a C++ library, it also has a
compatibility module for platforms lacking explicitly sized integers. If
it doesn't already work for C, you will probably be able to easily make it
work.

One thing though, which wasn't brought up yet: it is best to avoid such
types. Depending on the context, it might be necessary though.

Why should they be avoided?

 

[CBFalconer]

Thanks for that info. I looked up this file (<stdint.h>) on my
Linux box, and it is just what I was looking for.

However, I also have Microsoft Visual C++. I couldn't find
<stdint.h> in the include directory, so just to be sure I wasn't
missing something, I searched Microsoft's site by "stdint.h" and
got no matches.

I think the Microsoft tool chain doesn't have such a file. It
isn't clear what to do, because even Windows will run on some
64-bit platforms.

It doesn't exist under C90, only under C99. However limits.h
exists under both, so you could make your decisions based on the
values in that.

Most of the world has at least partially implemented C99, but
Microsoft is following its usual practice of undermining
standards. Just don't use any Microsoft software.

 

[Mark McIntyre]

David T. Ashley a écrit :


Just copy your linux stdint.h to your Microsoft installation...

This may or may not achieve anything, depending on how stdint.h
defines the types. You may also end up copying several other headers.
Some of these may contain architecture-specific details which simply
aren't portable, and you'll either end up with incorrect definitions,
or definitions which surprise you.

Generally headers are _not_ portable between implementations.

Of course you should remember that in 64 bit microsoft environment,
long is 32 bits and under 64 bit linux it is 64 bits. The file would
need at most a small editing change.

In my view, that sorta defeats the point. If you know the widths, then
you could just define the whole lot yourself in a private header with
a bunch of #ifs

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

 

[websnarf]

and it is just what I was looking for.

However, I also have Microsoft Visual C++. I couldn't find <stdint.h> in
the include directory, so just to be sure I wasn't missing something, I
searched Microsoft's site by "stdint.h" and got no matches.

I think the Microsoft tool chain doesn't have such a file. It isn't clear
what to do, because even Windows will run on some 64-bit platforms.

Just get this:

http://www.pobox.com/~qed/pstdint.h

Include that file for all platforms, and you are basically done. Its
as if all systems have a <stdint.h> at that point. Its not 100% (and
I accept feedback on making the file better) but it covers all the
most common, important scenarios.

 

[Keith Thompson]

Yes. Just copy your linux stdint.h to your Microsoft installation...

That's vanishingly unlikely to work. Does a Microsoft installation
happen to have headers called <features.h>, <bits/wchar.h>, and

NOT very difficult. stdint.h is standard C. Microsoft dpesn't always
comply with it but this is easy to follow.

Yes, stdint.h is standard C. It's also worth mentioning that it's new
in the C99 standard, which many compilers don't currently implement.

Of course you should remember that in 64 bit microsoft environment,
long is 32 bits and under 64 bit linux it is 64 bits. The file would
need at most a small editing change.

If you want an implementation of <stdint.h> that can be used with a
pre-C99 implementation, take a look at
<http://www.lysator.liu.se/c/q8/index.html>.

 

[Malcolm McLean]

Why should they be avoided?

It is just a nuisance to everyone if integers aren't ints. Very rarely it is
necessary to use a short type to save memory or a big type to hold a huge
value, but rarely.

ANSI have unfortunately decided that it is more important to support 4096
million character strings on 32 bit machines than to have a clean language,
and muddied the waters.

 

[christian.bau]

I'm writing code which will compile on multiple Windows and multiple *nix
platforms. Some will have 64-bit integers, I believe.

What is my best option to define platform-independent types such as UINT32
or UINT64? I'm not sure how to sort out the various platforms and integer
sizes, and some of it may even vary based on compiler options.

Start by including <limits.h>. If you want for example a 32 bit
unsigned type, check whether UINT_MAX is 0xffffffff, if not then check
whether ULONG_MAX is 0xffffff, otherwise #error (sort it out when you
run into the situation).

When running on a 64 bit system, you sometimes want 64 bit values
instead of 32 bit, and sometimes you don't. A variable that counts the
number of open windows in an application, or the number of children in
a family, doesn't have to be 64 bit. Variables counting the sizes of
things, or number of items, you will likely want to change in size on
a 64 bit system. I'd say checking whether SIZE_MAX == 2^64 - 1 is a
good indication. So you want some type that _does_ change on a 64 bit
system and needs to be named appropriately.

One hint: If you define such a type, give it a different type on a 32
bit vs. 64 bit system. For example, don't use long in both cases, but
use int for 32 bit (if it is large enough) and long for 64 bit (if it
is large enough). That way you can find mistakes where the wrong type
is used, because either on a 32 bit system or a 64 bit system the
compiler will produce an error.

 

[CBFalconer]

It is just a nuisance to everyone if integers aren't ints. Very
rarely it is necessary to use a short type to save memory or a big
type to hold a huge value, but rarely.

ANSI have unfortunately decided that it is more important to support
4096 million character strings on 32 bit machines than to have a
clean language, and muddied the waters.

Nonsense. ISO has decided that it is important to not invalidate
clean existing code, as did the ANSI committee about 20 years ago.
The result has been almost 100% acceptance of the C90 standard, and
C99 will eventually be accepted. However the urge to advance there
is much smaller, simply because C90 did such a good job, and some
C99 extensions are a bear to implement.

 

[santosh]

It is just a nuisance to everyone if integers aren't ints. Very rarely it is
necessary to use a short type to save memory or a big type to hold a huge
value, but rarely.

ANSI have unfortunately decided that it is more important to support 4096
million character strings on 32 bit machines than to have a clean language,
and muddied the waters.

One common complaint I hear from my colleagues, (who're Java bigots),
in defense of their reluctance to use C, is that it's types are too
few and primitive. I suppose it's a common argument on the bullet
lists of advocates of 4GLs.

 

[Malcolm McLean]

When running on a 64 bit system, you sometimes want 64 bit values
instead of 32 bit, and sometimes you don't. A variable that counts the
number of open windows in an application, or the number of children in
a family, doesn't have to be 64 bit.

No, but you need a lot of open desktops or a lot of families for it to
matter that the integer is 64 bits.

 

[Ian Collins]

What happend to the other attributions?

It is just a nuisance to everyone if integers aren't ints. Very rarely it is
necessary to use a short type to save memory or a big type to hold a huge
value, but rarely.

From the above I guess that you haven't worked on embedded systems or
drivers, where size very often does matter.

ANSI have unfortunately decided that it is more important to support 4096
million character strings on 32 bit machines than to have a clean language,
and muddied the waters.

Now that's just silly.

 

[Richard Heathfield]

santosh said:

One common complaint I hear from my colleagues, (who're Java bigots),
in defense of their reluctance to use C, is that it's types are too
few and primitive. I suppose it's a common argument on the bullet
lists of advocates of 4GLs.

I'm a great fan of 4GLs, but I see type multiplicity as something of a mixed
blessing. In any case, many of those 4GLs are written in C in the first
place. I once used a fabulous 4GL called KnowledgeMan. The language was a
sort of cross between C and BASIC. Types were almost non-existent, actually
- just numbers, strings, and database records, if I recall correctly. But
you got SQL, you got an evaluation operator for ripping the quotes off
strings, you got a built-in spreadsheet, you could read program code off
the disk and load it into the spreadsheet and then execute it from there
(because, would you believe, this was quicker - using the spreadsheet as a
sort of RAM disk)... oh, all sorts of tricks. It even had a sort of expert
system bolted on. That was one fabulous 4GL! But lotsatypes? No.

 

[Malcolm McLean]

From the above I guess that you haven't worked on embedded systems or
drivers, where size very often does matter.

When I campaign for 64 bit ints, that is on systems with 64 bit address
buses.

Oddly enough the last embedded system I programmed was a DSP which did have
wide integer types and no memory to speak of. However it didn't have a C
compiler.