Jason Zions <yyyyyyyy@xxxxxxxxxxxxx> wrote, on Wed 10 Jan 2001:
>
> Umm, what did people do on 32-bit systems which supported the Open Group LFS
> extensions when they wanted to output an off_t?
What I did was to write an `off_t to string' conversion function.
I imagine that's what most people did, since there was no facility
provided for formatting off_t values.
> Knowing as they did at the
> time that off_t would always be able to represent the largest useful integer
> on a system, careful programmers would have used off_t, rather than long, as
> the universal integral datatype.
There is no guarantee that off_t can represent the largest useful
(extended) integer. It might, for example, be smaller than intptr_t,
which was introduced in SUSv2 at the same time that off_t was changed
from an integral type to an extended integral type.
> In any event, there are certain things We Now Know Better. The one in
> question: we now know it's a bad idea to assume that all possible integral
> values fit into long.
In C90, POSIX.1-1996 and UNIX98 it is a *fact* that all possible values
for integer types fit into long, not an assumption.
In C99 it is no longer a fact, but that is because the definition of
"integer type" has changed, and so the very meaning of the statement
has changed.
At the moment, all we know is it's a bad idea to assume that all size_t
values fit into unsigned long *for pure C99 applications*. For POSIX
and UNIX applications it is still a safe assumption until the current
standards are superseded. We are in the process of deciding whether
to invalidate that assumption for the new POSIX and UNIX standards or
to let it still be valid. (Perhaps with a warning that it may become
invalid in a future revision.)
> - Some implementations will choose to make sizeof(long) == sizeof(size_t).
> Users with code which assumes this equivalence will acquire such platforms.
> - Other implementations will choose to make sizeof(long) < sizeof(size_t).
> Users with code not relying on such an equivalence will have a larger set of
> platforms from which to choose.
> - Application developers will know to write code which doesn't rely on this
> equivalence.
This is all well and good, but you are talking about well-informed
users. The danger is that naive users can grab the source for a
POSIX96 or UNIX98 application from the net, compile it on an
implementation where size_t is wider than long, and then be unaware
that the application is producing incorrect output or is silently
corrupting their data.
> The alternative, proposed by Geoff, is that we forbid implementors to build
> systems which make sizeof(long) < sizeof(size_t) until (possibly) some time
> in the future, when we will once again revisit this issue and perhaps allow
> vendors to build such systems.
The proposal does not forbid implementors to build systems with
size_t wider than long. It requires the implementors of such
systems who want them to be POSIX/UNIX conformant to provide an
additional compilation environment where size_t is no wider than
long, and to specify this compilation environment in their
conformance documentation.
--
Geoff Clare yyy@xxxxxxxxxxx
UniSoft Limited, London, England. yyy@xxxxxxxxxx
|