Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!elroy.jpl.nasa.gov!usc!samsung!rex!uflorida!gatech!purdue!haven!adm!smoke!gwyn
From: gwyn@smoke.brl.mil (Doug Gwyn)
Newsgroups: comp.lang.c
Subject: Re: int32 et al.
Message-ID: <14889@smoke.brl.mil>
Date: 17 Jan 91 23:24:09 GMT
References: <26@christmas.UUCP>
Organization: U.S. Army Ballistic Research Laboratory, APG, MD.
Lines: 25

In article <26@christmas.UUCP> rtm@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.