🚀 go-pugleaf

In article <48bjig$rgj@inca01.inca.co.nz>
           gmiller@inca.co.nz "Gaven Miller" writes:

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

So long as the compilers on a particular system agree (presumably if your
library is compiled on that system it will use one of those compilers) there
should be no problems.

Frankly the existing types provided by C work rather well - if you follow
some rather basic rules.

1. For a type that is efficient on the system and can store values in
at least the range +/-32767 -> int, 0 to 65535 -> unsigned int.

2. A type to hold characters and small integers especially in arrays or structs
   (0 to 127 -> char, +/-127 -> signed char, 0 to 255 -> unsigned char).

3. A type to use (usually) in arrays or structs where space considerations are
   important and required range is at least +/-32767 -> short, 0 to 65535 ->
   unsigned short.

3. A type to use when the range is greater than that guaranteed by short/int
   but within the range +/-2147473647 -> long, 0 to 4294967295 ->
   unsigned long.

I've found that covers virtually all cases. The only typedefs I've found useful
int32/uint32 to be used in arrays/structs where space is important
but a bigger range than that guaranteed by shorts/ints is needed.

A new version of the language standard should however add guaranteed support
for types longer than 32 bits. 64 bits (or greater) certainly, 128 bits
(or greater) possibly too.

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

These seem rather pointless (other than uint32). sint16 is to all intents and
purposes equivalent to short. schar8 can't be anything other than signed char.
To use the language (or at least the standard library) effectively you
ultimately need to know what the underlying type is. fprintf and fscanf
conversion specifiers are the most clear example of this. By trying to cover
up the underlying types you are ultimately asking for trouble, especially
when the basic language itself provides the tools to write portable code.
To effectively support that sort of usage you need a language with stronger
typing, such as one derived from PASCAL, or possibly C++'s OO support.

-- 
-----------------------------------------
Lawrence Kirby | fred@genesis.demon.co.uk
Wilts, England | 70734.126@compuserve.com
-----------------------------------------