🚀 go-pugleaf

Samuel John Kass (samkass+@CMU.EDU) wrote:
> It's my opinion that int's should be optionally postfixed with their
> size...
> ie. stdlib.h should define int8, int16, int32, int64.
> "int" alone should be whatever size the processor deals with best, and
> "short" and "long" can be whatever the compiler vendor deems best.
> 	--Sam

True, but for total portability, wouldn't it be wise to lose "int", 
"short" and "long"? I bet everyone who reads this could bring up at least 
one case of "Compiler X doesn't agree with Compiler Y on the size of 
short/int/long". And that is a problem if you distribute source code for 
Joe Public to use to interface to your program/library. 

When writing all of my new C code, I prefix the integer type name with 's'
or 'u' to note it's (un)signed status. So, my code is liberally sprinkled
with "sint16", "uint32", "schar8" types (signed 16-bit integer, unsigned
32-bit integer, signed 8-bit character).  And those are typedefs in a
include file (kept in "0/types.h" in my system, so the only thing I need 
to change when I move to another compiler/system is the include file). 

Of course this is not supported by ANSI C at present, but from what i've
read in the (Aug95?) DDJ, they are going to a "int32_t" for 32-bit
integers, "int16_t" for 16-bit integers. But, IMO, this does not convey 
the signed/unsigned nature of the integer - for me, prefixing an 's' or a 
'u' is much easier. The "_t" postfixed to the type identifier doesn't 
really do things for me, but, as a standard, it has merit (portability, 
"grep"-ability).

--

If I am wrong, flame AOL.
If I am right, flame AOL.
What the hell, just flame AOL.