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

[Zack Weinberg <zackw at panix dot com>]

On Fri, Sep 8, 2017 at 12:43 PM, Joseph Myers <joseph@codesourcery.com> wrote:
> 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.

Hmm, OK.

> 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.

That's a good point.  What I should have said is "before we do this,
we should inspect all affected interfaces and see whether any of them
are obsolete to the point where we should demote them to compat
symbols, at which point they don't need time64 versions".

stime is the only one I _know_ falls into that category: withdrawn in
XPG3 + completely superseded by newer APIs + niche usage (there are
very few programs that need to _set_ the system time, after all)
(unfortunately, a lot of the hits on codesearch.debian.net are
unrelated use of the same name, to the point where I can't actually
tell how many real uses there are, but I would bet any program that
still uses it does so only as a fallback-for-legacy-OSes from
clock_settime and friends).

>> * 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

Neither you, nor Rich, nor anyone else on the cited Austin Group
discussion has addressed the actual issue, which is that this is a
datum embedded in structures passed across the kernel/user boundary by
reference, it is impossible to enumerate all such structures,
therefore its type _must_ be a typedef so that it can be made to match
the kernel's expectations, whatever those might be.

(And I don't particularly see why people seem to think this is an
x32-specific issue.  It potentially affects *any* 32-bit ABI on a
64-bit kernel.)

>> <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.

<sys/types.h> doesn't exist in ISO C as far as I know, so how could it
be?  But any program that uses it opts into POSIX's specification for
that header, even if compiled with -std=c89 and no _foo_SOURCE
definitions.

zw