> From: Donn Terry <yyyyyy@xxxxxxxxxxxxx>
> Date: Thu, 11 Jan 2001 13:36:26 -0800
> (Some proposals have indicated that certain
> types, e.g. off_t, might be excepted from this, but I haven't seen
> a explicit proposal with what purports to be a complete list.)
There is an explicit list in XBDd4 ERN237. See:
http://www.opengroup.org/austin/docs/austin_60r2.txt
Basically, it exempts file-related types like off_t, as there is
demonstrated need for having them longer than long and they affect
applications less than size_t does.
> Applications which were not careful about types (in the abstract sense
> that would be enforced by Ada, at least), and which did make
> the assumption that "everything fits in a long".
This mischaracterizes the applications in question. Even some
applications that were quite careful about types (in the C sense) use
that assumption to get their work done.
> Applications which are fundamentally 32 bit applications (for whatever
> reasons) but which want to, for whatever reasons, access 64 bit off_ts.
These are common, but ERN237 would not affect them, as off_t is exempt.
> Applications which are fundamentally 32 bit applications which want
> to access 64 bit time_t. (Or uid_t, or any of the other defined types).
These must be quite rare. I've never heard of any.
> Applications which are fundamentally 32 bit applications, but which
> need 64 bit pointers.
If an app needs 64-bit pointers, I don't see how one can call it a
"fundamentally 32 bit application". If you need 64-bit pointers,
you're probably going to be using a lot of 64-bit integer arithmetic.
Such apps will be compiled using a 64-bit model.
Therefore, none of the application classes that you've talked about
support the case against ERN237.
> Traditionally int has been used for "I don't really care, make it
> fast" (and a synonym for one of the other types). However, given
> the limited namespace for types, this situation requires int to be
> 32 bits, which may not be the "natural" size for some architectures.
Once C99 is in place, we can handle this problem by having people use
int32_t for 32-bit integer, and int for "fast integer". Or you can
use one of the C99 "fast" types if you like, though that's less elegant.
> (Besides which, what do we do when we want 128 bit types for things
> like file offsets;
That will be a long, long time from now, and by then we can assume C99
solutions like int128_t.
> We're just now moving in the direction of their 64 bit types
> relatively common, but there will be a need for 128 bit types
> developing over time, well before the hardware gets there.)
True, but again: this won't occur before the next POSIX round.
We have plenty of time.
> (Ideally, a new "time_t" would be >64 bits now;
Also true, but futzing with time_t is beyond the scope of this POSIX
round, so it is irrelevant here.
> But let's not declare those vendors that find a business
> need for objects bigger than long to be nonconforming because SOME
> programmers haven't yet made the transition.
We're not arguing that those vendors have to be nonconforming. If
they have a business need, they can provide a nonstandard environment
as well as a standard one. This is common practice.
> (You can argue about "poorly written", but if the application used
> long where it should have used some _t type, I think it qualifies,
> "guarantee" of legality for that not withstanding.)
But the cases we're talking about is where the current standard
provides no _t type; unsigned long or long is the only reasonable
possibility. For example, the current standard provides no convenient
way to print a process-id other than something like
`printf("%ld", (long)pid)'. There is nothing poorly-written about
that code right now.
> There's no reason to require that ANY application with this problem be
> ever compiled with C99,
So, you're saying that there's no reason that the current version of
Apache should ever be compiled with C99? Yes -- like many other
popular programs, Apache has this problem in spades.
What kind of a standardization process would change a standard incompatibly,
and invalidate common, popular applications like Apache?
> However, there are other application writers who would consider
> exactly the sort of implementation that it is being proposed to
> prohibit to be the ideal implementation for their needs.
Who are these application writers? So far, I haven't heard from any.
The only people I've heard pushing this incompatible change are system
vendors and implementers.
I'm an application writer. I would love to hear from other POSIX
application writers. I want to hear their explanations as to why they
want size_t to be longer than long.
> On "give us time to make the transition": Y2K didn't get the
> attention it should have (until the last minute)
We're talking about at least 20 years before the transition to 128-bit
size_t is needed. In the first 10 years, the size_t<=long assumption
would be marked as obsolescent. In the second 10 years, the
assumption would be invalid. That is plenty of time.
> A standard that provides a business excuse to avoid doing
> the right thing
What is the "right thing"? So far, the best that has been proposed
for making applications portable between the current standard and d5
is to go through all the code and write stuff like this:
sprintf (message,
#if HAVE_J_PRINTF_FORMAT_SPEC
_("Could only read %ju of %ju bytes"),
#else
_("Could only read %lu of %lu bytes"),
#endif
(uintmax_t) status, (uintmax_t) bytes);
This is not the "right thing". And that is just the problem of printf
formats; it is not the only problem caused by this incompatible change
to the standard.
|