Re: [RFC PATCH 00/52] Make GLIBC Y2038-proof

[Joseph Myers <joseph at codesourcery dot com>]

On Fri, 8 Sep 2017, Zack Weinberg wrote:

> * I understand that you are trying to make the transition as seamless
> as possible with _TIME_BITS and so on, but I would seriously question
> whether it is appropriate to preserve super-legacy APIs such as
> 'stime' and 'utime' in the extended mode.  (I'd put the cutoff at
> 'gettimeofday', which is still heavily used even though
> 'clock_gettime' officially supersedes it.)

I don't think utime is super-legacy; it's in the 2008 edition of POSIX.  
Now, stime is not part of any supported standard (it was withdrawn in 
XPG3) - such old BSD/SVID interfaces that are now in __USE_MISC but no 
other standard are definitely worth considering for obsoletion (removing 
declarations / documentation, making into compat symbols not available for 
new ports / static linking) if there are clear replacements for any 
current uses / not much current use.  And such obsoletion for nonstandard 
time-related interfaces may well be a useful preliminary to reduce the 
number of interfaces needing _TIME_BITS=64 versions.  (Many such 
interfaces are of course not time-related but just as deserving of 
consideration for obsoletion; in general obsoletion of one such interface 
is independent of obsoletion of any others.)

> * The POSIX (and ISO C now, argh) requirement for tv_nsec to be 'long'
> is, as discussed at great length earlier, incorrect and should be
> ignored.  It should instead be a new typedef 'nsec_t' available in

And as discussed, I disagree and don't think we should invent any such 
typedef or deviate from this requirement, given that long is fully able to 
represent all valid nanoseconds values, in the absence of clear evidence 
that POSIX and ISO C agree with removing that requirement (e.g. an Austin 
Group issue tagged issue8 with accepted changes for the next revision of 
POSIX, combined with acceptance for C2X in WG14 minutes of the issue 
raised by the Austin Group liaison - or a WG14 change accepted for C2X 
with agreement on the Austin Group side following the change being passed 
in the other direction).  When the matter was raised with the Austin Group 
in May 2014, no-one contradicted Rich Felker's comment (which I agree 
with) that the x32 issue is just a Linux kernel bug which needs to be 
fixed.  (I think this use of long is *less* of an issue than e.g. printf 
returning int, since you can legitimately print more characters than fit 
in int.)

> <sys/types.h>, matching the kernel's choice of 32 or 64 bits for this
> field (all _t names are reserved for future extension, so the typedef
> doesn't need to be _GNU_SOURCE-only). This "willful violation" (as the

They are not reserved in ISO C, only in POSIX.

-- 
Joseph S. Myers
joseph@codesourcery.com