int32 et al.

[Doug Gwyn]

In article <26 at christmas.UUCP> rtm at island.COM (Richard Minner) writes:
>I've gathered from this discussion (and others) that it is unlikely
>that long will ever be implemented to be larger than int, unless int
>is less than 32-bits (in a `quality' implementation?).  Is this so?

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.

At present there is a lot of nonportable code that discourages some
vendors (I know of one for sure) from implementing C with
sizeof(long)!=sizeof(int) or even sizeof(int)!=4.  However, one would
hope that programmers would eventually learn better than to write code
that unnecessarily depends on such things.

>... using long could possibly be `wasteful' (of space and time) if
>your code lived long enough to be ported to, say, 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.