From: tomw AT tsys DOT demon DOT co DOT uk (Tom Wheeley)
Newsgroups: comp.os.msdos.djgpp
Subject: Re: Weird problem
Date: Sun, 23 Mar 97 01:53:25 GMT
Organization: Adventures and Diving
Message-ID: <859082005snz@tsys.demon.co.uk>
References: <Pine DOT D-G DOT 3 DOT 91 DOT 970321100757 DOT 14756B-100000 AT dg1> <01bc3643$03652400$LocalHost AT anthonyb>
Reply-To: tw104 AT york DOT ac DOT uk
Lines: 39
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp

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)