Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!udel!haven!adm!smoke!gwyn
From: gwyn@smoke.brl.mil (Doug Gwyn)
Newsgroups: comp.lang.c
Subject: Re: int32 et al.
Message-ID: <14905@smoke.brl.mil>
Date: 20 Jan 91 08:34:26 GMT
References: <26@christmas.UUCP> <867@TALOS.UUCP> <1991Jan19.185101.27554@odi.com>
Organization: U.S. Army Ballistic Research Laboratory, APG, MD.
Lines: 18

In article <1991Jan19.185101.27554@odi.com> benson@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.

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