From: jamshid@ut-emx.uucp (Jamshid Afshar)
Newsgroups: comp.lang.c
Subject: Re: Typedefing builtin... thanks.
Date: 21 Nov 92 23:30:53 GMT
Reply-To: jamshid@emx.utexas.edu
Organization: The University of Texas at Austin; Austin, Texas

In article <1992Nov13.172005.28239@alf.uib.no> yngvar@imr.no (Yngvar Foelling) writes:
>In article <1992Nov11.061812.21905@sq.sq.com>, msb@sq.sq.com (Mark Brader) writes:
>|>>A program is easier to port, when you can change some typedefs in a header
>|>>file, instead of changing a lot of ints to longs all over the code.
>|> 
>|> If the code was correctly written, those ints would have been longs
>|> in the first place.  See item 10.1 in the FAQ list.
>
>Yes, let's.  Particularly the last paragraph:
>
>        If for some reason you need to declare something with an _exact_
>        size [...], be sure to encapsulate the choice behind an
>        appropriate typedef.
>
>In this case, it seems like Jonatan Kutchinsky _was_ trying to match an
>"externally-imposted storage layout".  He wanted to simulate a particular
>processor.

I don't think Mark was commenting on the use of typedefs in that
situation, but on the general advice recommending the use of typedefs
like |int32| instead of |int| or |long|.  Besides, I don't think it's
necessary that the simulator use the same exact number of bits to
represent a byte or word in the simulated processor.  For example, say
the processor to be simulated has 16-bit words.  I would typedef
simword_t as an |int| and would write the code such that it works when
compiled under a machine with either 16-bit or 32-bit ints.

I just don't understand how a typedef like int32 is useful in general
applications.  For one thing, you are not guaranteed that there exists
an integral type with exactly that many bits -- imagine an
implementation where all integral types are 64-bits.  Typedefs can
greatly aid readability and encourage implementation hiding, but I
don't think typedefs like int32 buy much.  Why not just use |long|
since it is guaranteed to be at least 32 bits?  At the very least use
<limits.h> and #if's to select the appropriate type instead of
requiring header file changes when porting.

>BTW, does anyone know about a C-compiler with 64-bit longs?  Even if there
>aren|t any right now, it seems to me that one would have to be written to take
>advantage of 64-bit architechtures.  In that case, using long instead of int
>would be overkill.

Not necessarily.  First, |long| would still be efficient -- they
wouldn't make it 64-bits unless it could handle 64-bits well (not to
mention the machine will probably be several times faster...).
Second, who's to say that |int| and |long| won't be the exact same
size as they are in many current implementations of C?  In fact, these
64-bit machines will/do probably have |int|==|long| because so much
code that would be ported to them makes the (incorrect) assumption
that they are the same size or that an |int| is the same size as a
|char*|.  Finally, don't forget that the implementation might impose
alignment requirements that would cause the use of one or the other to
only make a difference in very large arrays.  An |int| as a struct
member might just be padded to use the same space as a |long|, or may
require more instructions to be accessed if it were "packed".

Jamshid Afshar
jamshid@emx.utexas.edu
Newsgroups: comp.lang.c