NetNews Usenet Archive 1992 #27/NN_1992_27.iso/spool/comp/lang/c/16967

Internet Message Format | 1992-11-21 | 3.5 KB

Path: sparky!uunet!zaphod.mps.ohio-state.edu!cs.utexas.edu!ut-emx!jamshid
From: [e-mail] (Jamshid Afshar)
Newsgroups: comp.lang.c
Subject: Re: Typedefing builtin... thanks.
Message-ID: <[e-mail]>
Date: 21 Nov 92 23:30:53 GMT
References: <[e-mail]> <[e-mail]> <[e-mail]>
Reply-To: [e-mail]
Organization: The University of Texas at Austin; Austin, Texas
Lines: 58

In article <[e-mail]> [e-mail] (Yngvar Foelling) writes:
>In article <[e-mail]>, [e-mail] (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
[e-mail]