This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Fifth draft of the Y2038 design document
On Wed, Feb 22, 2017 at 4:01 PM, Joseph Myers <joseph@codesourcery.com> wrote:
> On Wed, 22 Feb 2017, Zack Weinberg wrote:
>
>> Speaking of struct timespec, though, why does this spec not consider
>> the possibility of changing the type of 'tv_nsec' to a new typedef,
>> say nsec_t, which can vary between 32- and 64-bit modes? Yes, this
>> requires a change in POSIX (and ISO C as well now, unfortunately), but
>> one that would be a good idea *anyway*.
>
> That's a gratuitous incompatibility with the existing standards (see Rich
> Felker passim, e.g. bug 16437).
In the specific case of tv_nsec, I am so convinced that the bare
'long' is a bug in the standards that I think we should just go ahead
and introduce nsec_t unilaterally. I am 100% serious.
> Adding typedefs makes sense when there is
> a use for storing values that cannot be represented in the current type.
> But long is guaranteed to be able to store all valid tv_nsec values (plus
> the extra value UTIME_NOW and UTIME_OMIT).
That's not the only reason. In this case, nsec_t would eliminate an
entire class of problems relating to passing a structure containing
(recursively) a 'struct timespec' across a integer-width discontinuity
-- which we already have to do for the sake of LP32 (and to a lesser
extent P32L64) user processes running on a LP64 kernel. _TIME_BITS=64
expands that problem to all LP32 kernels as well.
zw