int32 et al.

[Benson I. Margulies]

In article <14905 at smoke.brl.mil> gwyn at smoke.brl.mil (Doug Gwyn) writes:
>In article <1991Jan19.185101.27554 at odi.com> benson at odi.com (Benson I. Margulies) writes:
>>Some of us use structs to lay our persistent (that is, disk-resident)
>>storage. The size of the items never changes, as we move from platform
>>to platform. If we used int for a 32 byte int, we are nailed on the
>>PCs. If we use long, C++ compilers tend to moan piteously about
>>passing longs to int parameters, even when they are the same size. The
>>AIX ANSI C compiler does the same. So we have a typedef which we set
>>to int on some places, and long on others. If someone ever does turn
>>up with 64 bit longs, we will pat each other on the back and save
>>a lot of work.
>
>But you didn't address the problems I pointed out, for example the
>complete lack of ANY type whose size if precisely 32 bits in some
>implementations.

Well, if we ever hit such a beast, there's always

typedef char [4] int32;

and a lot of unpleasant accessor macros.  However, we have a real
problem today with 16 and 32 bit in machines, which the obvious
typedefs solve. I don't disagree that wierder machines will provide
other problems.

>
>I also don't understand the type mismatch problem.  Certainly you
>should make all types match properly, no matter what choice you
>have made for the "int32"s.  It is not just C++ that should complain..

The system include files contain

extern int blahblah (int, char *);

I don't control that declaration. If I call blahblah with a long,
the compiler bleats a warning.

for 

extern int quux (int *);

if I pass a long * I get an error, not just a warning.
So I can't just use long all the time unless I type in all my
own system function prototypes.

-- 
Benson I. Margulies