Mail Archives: djgpp/1997/03/21/20:14:36
ANSI really does need to define these better. It was intended to make
portablility easier, when in fact it makes it harder. Unless someone
thinks that computers will all of a sudden start using 7 or 9 bit
structures, they need to define the symbols for particular data sizes.
Something like INT8, INT16, INT32, INT64, INT128 and so on would make
portability a snap. Right now the best way to guarantee data sizing is to
define it as a bit field of X length.
--
::-)
----------------------------------------------------------------------------
---
HTTP://vax2.rainis.net/~cwhizard/norn.htm
Home of the Sixpak of Norns.
To reply to a news posting, remove the
anti-SPAM features from my e-mail address.
art s. kagel IFMX x2697 <kagel AT dg1 DOT bloomberg DOT com> wrote in article
<Pine DOT D-G DOT 3 DOT 91 DOT 970321100757 DOT 14756B-100000 AT dg1>...
>
> I did not miss the point. But you have missed mine. I state that if the
> range is important use short or long explicitely and only use int for
> efficiently (and that even this fails on 64bit machines). The point I
> wished to make and, unfortunately, only implied is that by doing things
> this way one knows to verify that the shorts and longs are large enough
> when porting and need not worry about ints at all.
>
> I use short only to save storage when a 16bit integer is sufficient, int
> only for array indices and loop variables when the range is limited, and
> long for everything else. In this way when porting I just have to make
> certain that shorts are at least 16 bits and maybe verify that longs are
> at least 32 bits (if any data has that requirement) and make one or two
> quick editor changes if not. If I am going to a 64 bit machine I can
> edit/sed/awk the int's to longs and I am done.
>
> The paranoid version of this is to #define or typedef new types like:
> int16, int32, intmachine and use these exclusively having to then only
> change three lines in an include file. However, I have never been
> paranoid and I know that, ANSI standard aside, there are no machines to
> which I will port my code that do not have 16 bit shorts and 32+bit longs
> and that any 64 bit machine is so damned fast that I may not care that
> my loop variables are not 64 bit integers; so my method is minimal cost
in
> the real world.
>
> Art S. Kagel, kagel AT ts1 DOT bloomberg DOT com
>
> On Tue, 18 Mar 1997, Erik Max Francis wrote:
>
> > art s. kagel IFMX x2697 wrote:
> >
> > > You're right, my apologies. However, my point still holds. Use
short or
> > > long if you care about storage size or value range and int only when
the
> > > range is irrelevant, as almost any wordsize will do, and/or
performance
> > > is paramount. Any use of int is frought with portability dangers.
> > > Especially since most 64-bit compilers actually have long as the
machine
> > > word size and int as a 32-bit integer.
> >
> > But you missed the point. The ANSI C standard makes no explicit size
> > definitions of shorts, ints, or longs, save that shorts are no larger
than
> > ints and longs are no smaller than ints. If the absolute size of ints
> > aren't specified (which they aren't), then neither are the sizes of
shorts
> > or longs.
> >
> > --
> > Erik Max Francis, &tSftDotIotE / email: max AT alcyone DOT com
> > Alcyone Systems / web:
http://www.alcyone.com/max/
> > San Jose, California, United States / icbm: 37 20 07 N 121 53 38 W
> > \
> > "I am become death, / destroyer of worlds."
> > / J. Robert Oppenheimer (quoting
legend)
> >
>
- Raw text -