Mail Archives: djgpp/1997/03/23/23:12:15
In article <01bc3643$03652400$LocalHost AT anthonyb>
cwhizard AT NOSPAM DOT sockets DOT net "Anthony Q. Bachler" writes:
> ANSI really does need to define these better. It was intended to make
> portablility easier, when in fact it makes it harder. Unless someone
> thinks that computers will all of a sudden start using 7 or 9 bit
> structures, they need to define the symbols for particular data sizes.
> Something like INT8, INT16, INT32, INT64, INT128 and so on would make
> portability a snap. Right now the best way to guarantee data sizing is to
> define it as a bit field of X length.
Bitfields? they're probably the least portable part of C!
Usage of ints is quite simple:
int for a general integer. This is guaranteed to be at least 16bit
long for 16-32bit numbers; greater than 32bit if you want to push it.
(not recommended at all)
short for space saving of numbers <= 16 bits. Useful if you have a large
array of small numbers. (even better if you have a large array of
paired shorts, as you're much more likely to optimize re word size)
The *only* non-portable aspects are:
1) Using ranges outside of the above (eg if you use an int on djgpp it is
32bit, when on other machines it could be 16 bit. The proper solution
here is to use long).
2) (the biggie) File I/O. This is where you need to know the size of the
number if you are going to read it directly. A safer assumption here is
to assume that char is 8 bits, and read in and construct numbers manually,
this can also aid with endian-conversions. Probably the proper way to do
this is to define int_32, uint_16 etc, and define endian-swapping macros
or functions; then have a complex config.h to manage it all based on
system predefines.
--
:sb)
- Raw text -