int32 et al.

[Richard Minner]

In article <14889 at smoke.brl.mil> gwyn at smoke.brl.mil (Doug Gwyn) writes:
>In article <26 at christmas.UUCP> rtm at island.COM (Richard Minner) writes:
>>I've gathered that it is unlikely that long will ever be larger than int,
>>unless int is less than 32-bits...
>
>No, I would disagree.  As file systems get ever larger, pressure to
>directly implement the (type "long") file offsets with more than 31-
>bit range will increase.  Thus, even if the architecture encourages
>32-bit integer representation, "long" could well be implemented as
>e.g. a 64-bit quantity, simply to reduce hassles for customers of
>such systems.
>
Hmmm. That's what I generally thought at first, but then got the
idea that `long long' would likely become the de facto standard
way to handle `longer than int, longer than 32-bit' longs.  (Hey,
why not looong, or longer and longest (for 128-bits)?)

Given your reasonable reasoning, I may reconsider using `int32'.
(int8 and int16 (and int17, int29 etc.) still seem unnecessary,
unless one did a lot of work on a machine with 18-bit shorts and
really needed the extra 2 bits, but...)

>>... using long could possibly be `wasteful' (of space and time)
>>[in] an environment with 32-bit ints and 64-bit longs.
>
>But the effort needed to design and write applications that try to
>accommodate "optimal" choices for such throw-away data types as counters
>probably exceeds any savings that would be gained thereby, in most cases.

Come again?  I usually appreciate your terseness, but you lost me here.
My code may be unusual (graphics, mostly rasters at present), but I
have a lot of code that would be hurt if longs were more than 32-bits
and ints weren't.  If a simple int32 def in one config file could
help, I'd rather use that than a bunch of independent typedefs all doing
the same thing.  Please elaborate if I missed something.
-- 
Richard Minner  rtm at island.COM  {uunet,sun,well}!island!rtm
Island Graphics Corporation  Sacramento, CA  (916) 736-1323