int32 et al.
Richard Minner
rtm at christmas.UUCP
Tue Jan 22 15:32:25 AEST 1991
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
More information about the Comp.lang.c
mailing list