HARRIS FLAME Re: SHORT vs. INT

[rex ballard]

> In article <2778 at sun.uucp> guy at sun.uucp (Guy Harris) writes:
> >People who use the C language should be sufficiently expert that they
> >understand that "long" and "short" should not be selected in favor of "int"
> 
>     I follow you so far ...
> 
> >only if they are of different sizes on the machine you're coding on.
> 
>     But I can't quite fiqure out what you mean here.  Does it mean that is
>   if 'short' 'int' and 'long' are the same size then I should choose
>   something other than 'int'?
> 
> >Period.  If a C programmer doesn't understand that, then they have not been
> >adequately trained in the C language and should not use the C language until
> >they have been so trained. 

Even the "wizards" of C can get 'bit' in unfamiliar situations.

A very good example of a case where short than "int" is when communicating
binary information between two dissimilar processors.  If a 68000 compiler
consideres int to be 16 bits, and a 68020 compiler treats it as 32 bits,
packed structures had better be very specific.

There are cases for it where space (communication time, disk access time,
and available storage) may be a deciding factor.  Consider the
option of sending time samples between two machines at 9600 baud.

Perhaps it is time to considere standardizing the size of char, long, and
short.  At least we should have some small "guarenteed size" of unit like
type "byte", which could always be 8 bits unsigned (or signed- vote on it).
The Honeywell 6000 uses a 9 bit char, how would you impart packed
binary information to it (where every bit is significant)?

Speaking of inter-processor communications, how about a binary
"packf()/unpackf()" function for the library.  It can get real hairy
trying to get a complex structure of long words, shorts, and chars
between a VAX or PDP-11 and a 68000 in binary form.  For that matter
letting a 68000 and an 8088 share the same disk can do real strange
things to "plot(5)" and similar binary files that write different order
& length "ints".  It's not always practical to store everything in text.