From: Zack Weinberg <zackw@panix.com>
To: Joseph Myers <joseph@codesourcery.com>
Cc: "Albert ARIBAUD (3ADEV)" <albert.aribaud@3adev.fr>,
GNU C Library <libc-alpha@sourceware.org>
Subject: Re: [RFC PATCH 00/52] Make GLIBC Y2038-proof
Date: Fri, 08 Sep 2017 17:01:00 -0000 [thread overview]
Message-ID: <CAKCAbMjgCjA-jMrCt9YDhw6dM5Y9MKJGn3=Bte-kF00Y-9SUdg@mail.gmail.com> (raw)
In-Reply-To: <alpine.DEB.2.20.1709081626530.16313@digraph.polyomino.org.uk>
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
next prev parent reply other threads:[~2017-09-08 17:01 UTC|newest]
Thread overview: 76+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-07 22:42 Albert ARIBAUD (3ADEV)
2017-09-07 22:42 ` [RFC PATCH 01/52] Y2038: add type __time64_t Albert ARIBAUD (3ADEV)
2017-09-07 22:42 ` [RFC PATCH 02/52] Y2038: add function __difftime64 Albert ARIBAUD (3ADEV)
2017-09-07 22:42 ` [RFC PATCH 03/52] Y2038: add functions using struct tm Albert ARIBAUD (3ADEV)
2017-09-07 22:42 ` [RFC PATCH 04/52] Y2038: add function __mktime64 (and timelocal) Albert ARIBAUD (3ADEV)
2017-09-07 22:42 ` [RFC PATCH 05/52] Y2038: add function __timegm64 Albert ARIBAUD (3ADEV)
2017-09-07 22:42 ` [RFC PATCH 06/52] Y2038: add struct __timespec64 Albert ARIBAUD (3ADEV)
2017-09-07 22:42 ` [RFC PATCH 07/52] Y2038: add function __clock_gettime64 Albert ARIBAUD (3ADEV)
2017-09-07 22:43 ` [RFC PATCH 08/52] Y2038: add function __clock_settime64 Albert ARIBAUD (3ADEV)
2017-09-07 22:43 ` [RFC PATCH 09/52] Y2038: add function __clock_getres64 Albert ARIBAUD (3ADEV)
2017-09-07 22:43 ` [RFC PATCH 10/52] Y2038: add function __clock_nanosleep64 Albert ARIBAUD (3ADEV)
2017-09-07 22:43 ` [RFC PATCH 11/52] Y2038: add function __timespec_get64 Albert ARIBAUD (3ADEV)
2017-09-07 22:43 ` [RFC PATCH 12/52] Y2038: add function __futimens64 Albert ARIBAUD (3ADEV)
2017-09-07 22:43 ` [RFC PATCH 13/52] Y2038: add function __utimensat64 Albert ARIBAUD (3ADEV)
2017-09-07 22:43 ` [RFC PATCH 14/52] Y2038: add function __sigtimedwait64 Albert ARIBAUD (3ADEV)
2017-09-07 22:43 ` [RFC PATCH 15/52] Y2038: add struct __timeval64 Albert ARIBAUD (3ADEV)
2017-09-07 22:43 ` [RFC PATCH 16/52] Y2038: add function __futimes64 Albert ARIBAUD (3ADEV)
2017-09-07 22:43 ` [RFC PATCH 17/52] Y2038: add function __lutimes64 Albert ARIBAUD (3ADEV)
2017-09-07 22:43 ` [RFC PATCH 18/52] Y2038: add struct __itimerspec64 Albert ARIBAUD (3ADEV)
2017-09-07 22:43 ` [RFC PATCH 19/52] Y2038: add function __timer_gettime64 Albert ARIBAUD (3ADEV)
2017-09-07 22:43 ` [RFC PATCH 20/52] Y2038: add function __timer_settime64 Albert ARIBAUD (3ADEV)
2017-09-07 22:43 ` [RFC PATCH 21/52] Y2038: add function __timerfd_gettime64 Albert ARIBAUD (3ADEV)
2017-09-07 22:44 ` [RFC PATCH 22/52] Y2038: add function __timerfd_settime64 Albert ARIBAUD (3ADEV)
2017-09-07 22:44 ` [RFC PATCH 23/52] Y2038: add struct __stat64_t64 Albert ARIBAUD (3ADEV)
2017-09-07 22:44 ` [RFC PATCH 24/52] Y2038: add function __fstat64_t64 (and __fxstat64_t64) Albert ARIBAUD (3ADEV)
2017-09-07 22:44 ` [RFC PATCH 25/52] Y2038: add function __stat64_t64 (and __xstat64_t64) Albert ARIBAUD (3ADEV)
2017-09-07 22:44 ` [RFC PATCH 26/52] Y2038: add function __lstat64_t64 (and __lxstat64_t64) Albert ARIBAUD (3ADEV)
2017-09-07 22:44 ` [RFC PATCH 27/52] Y2038: add function __fstatat64_t64 (and __fxstatat_t64) Albert ARIBAUD (3ADEV)
2017-09-07 22:44 ` [RFC PATCH 28/52] Y2038: add function __time_t64 Albert ARIBAUD (3ADEV)
2017-09-07 22:44 ` [RFC PATCH 29/52] Y2038: add function __stime_t64 Albert ARIBAUD (3ADEV)
2017-09-07 22:44 ` [RFC PATCH 30/52] Y2038: add function __utimes_t64 Albert ARIBAUD (3ADEV)
2017-09-07 22:44 ` [RFC PATCH 31/52] Y2038: add function __gettimeofday_t64 Albert ARIBAUD (3ADEV)
2017-09-07 22:44 ` [RFC PATCH 32/52] Y2038: add function __settimeofday_t64 Albert ARIBAUD (3ADEV)
2017-09-07 22:44 ` [RFC PATCH 33/52] Y2038: add function __mq_timedsend_t64 Albert ARIBAUD (3ADEV)
2017-09-07 22:44 ` [RFC PATCH 34/52] Y2038: add function __mq_timedreceive_t64 Albert ARIBAUD (3ADEV)
2017-09-07 22:44 ` [RFC PATCH 35/52] Y2038: add function __msgctl_t64 Albert ARIBAUD (3ADEV)
2017-09-07 22:45 ` [RFC PATCH 36/52] Y2038: add function __sched_rr_get_interval_t64 Albert ARIBAUD (3ADEV)
2017-09-07 22:45 ` [RFC PATCH 37/52] Y2038: add function __nanosleep64_t64 Albert ARIBAUD (3ADEV)
2017-09-07 22:45 ` [RFC PATCH 38/52] Y2038: add function __adjtime_t64 Albert ARIBAUD (3ADEV)
2017-09-07 22:45 ` [RFC PATCH 39/52] Y2038: add function __utime_t64 Albert ARIBAUD (3ADEV)
2017-09-07 22:45 ` [RFC PATCH 40/52] Y2038: add struct __itimerval_t64 Albert ARIBAUD (3ADEV)
2017-09-07 22:45 ` [RFC PATCH 41/52] Y2038: add function __getitimer_t64 Albert ARIBAUD (3ADEV)
2017-09-07 22:45 ` [RFC PATCH 42/52] Y2038: add function __setitimer_t64 Albert ARIBAUD (3ADEV)
2017-09-07 22:45 ` [RFC PATCH 43/52] Y2038: add functions using futexes Albert ARIBAUD (3ADEV)
2017-09-07 22:45 ` [RFC PATCH 44/52] Y2038: add function __getrusage_t64 Albert ARIBAUD (3ADEV)
2017-09-07 22:45 ` [RFC PATCH 45/52] Y2038: add struct __ntp_timeval_t64 Albert ARIBAUD (3ADEV)
2017-09-07 22:45 ` [RFC PATCH 46/52] Y2038: add function __ntp_gettime_t64 Albert ARIBAUD (3ADEV)
2017-09-07 22:45 ` [RFC PATCH 47/52] Y2038: add function __ntp_gettimex_t64 Albert ARIBAUD (3ADEV)
2017-09-07 22:45 ` [RFC PATCH 48/52] Y2038: add function __adjtimex_t64 (and __ntp_adjtime_t64) Albert ARIBAUD (3ADEV)
2017-09-07 22:46 ` [RFC PATCH 49/52] Y2038: add function pselect Albert ARIBAUD (3ADEV)
2017-09-08 17:49 ` [RFC PATCH 50/52] Y2038: add function select Albert ARIBAUD (3ADEV)
2017-09-08 17:49 ` [RFC PATCH 51/52] Y2038: add RPC functions Albert ARIBAUD (3ADEV)
2017-09-08 17:49 ` [RFC PATCH 52/52] Y2038: add _TIME_BITS==64 support Albert ARIBAUD (3ADEV)
2017-09-08 19:47 ` Joseph Myers
2017-09-08 19:47 ` [RFC PATCH 51/52] Y2038: add RPC functions Joseph Myers
2017-09-08 19:59 ` Paul Eggert
2017-09-09 14:37 ` Albert ARIBAUD
2017-09-11 6:33 ` Paul Eggert
2017-09-11 7:06 ` Paul Eggert
2017-09-11 14:07 ` Paul Eggert
2017-09-11 15:59 ` Albert ARIBAUD
2017-09-07 23:21 ` [RFC PATCH 00/52] Make GLIBC Y2038-proof Joseph Myers
2017-09-08 16:19 ` Zack Weinberg
2017-09-08 16:43 ` Joseph Myers
2017-09-08 16:54 ` Paul Eggert
2017-09-08 17:01 ` Zack Weinberg [this message]
2017-09-08 17:24 ` Joseph Myers
2017-09-08 18:32 ` Zack Weinberg
2017-09-08 17:42 ` Albert ARIBAUD
2017-09-08 17:59 ` Joseph Myers
2017-09-08 18:16 ` Albert ARIBAUD
2017-09-08 18:36 ` Zack Weinberg
2017-09-08 17:08 ` Albert ARIBAUD
2017-09-08 17:26 ` Joseph Myers
2017-09-08 19:19 ` Albert ARIBAUD
2017-09-08 4:23 ` Albert ARIBAUD
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAKCAbMjgCjA-jMrCt9YDhw6dM5Y9MKJGn3=Bte-kF00Y-9SUdg@mail.gmail.com' \
--to=zackw@panix.com \
--cc=albert.aribaud@3adev.fr \
--cc=joseph@codesourcery.com \
--cc=libc-alpha@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).