The guarantee that size_t <= long also exists now, is standard, and exists
on all of the platforms that I know about. The guarantee that int is
32-bits is not standard and is not explicitly guaranteed anywhere. The
types created to deal with this situation (uint32_t, etc.) exist now,
have for some time, are standard, are now (finally) in common use. The
various extensions to manipulate size_t, ptr_diff_t, etc, safely in the
face of *removing* the *existing* *standardized* guarantee have just
popped into existance and are available on exactly *one* of the platforms
I am interested in (out of about a dozen). If you ask me ten years from
now, I just *might* concede that the situations were comparable.
In any case, defending the removal of the existing guarantee in the name
of the poor $^%^@#^ who are still expecting to write a long to disk and
get it back intact, makes no sense whatsoever. You *might* convince me
that *deprecating* the current guarantee could be reasonable if you can
come up with a much better reason than that.
On 10 Jan 2001, Ulrich Drepper wrote:
> Eric Vought <yyyyyyy@xxxxxxxx> writes:
>
> > That is why uint32t and so forth exist. If an application needs to
> > maintain compatibility with a 32 (or 64) bit API, then the application
> > should be using the types that were specifically created for that
> > purpose.
>
> So you are in fact supporting what I said namely that programmers
> should use the right types (size_t, ptrdiff_t) if the variables are
> used for this purpose. And following, that there is no reason to
> limit size_t and ptrdiff_t in relation to long or long long or long
> long long ...
>
>
--
Eric Vought
Chief Technical Officer - QLUE Consulting, Inc.
yyyyyyy@xxxxxxxx toll-free: 888.771.3538 RTP area: 919.816.9901
|