This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH v2] Y2038: add function __localtime64
On Wed, 12 Dec 2018, Albert ARIBAUD wrote:
> Hi Joseph,
>
> On Wed, 12 Dec 2018 17:09:22 +0000, Joseph Myers
> <joseph@codesourcery.com> wrote :
>
> > > +@item
> > > +Y2038 support code added to @theglibc{} must not modify or remove
> > > +existing symbols on 32-bit time architectures. This ensures that
> > > +existing user object code will remain able to link against the newer
> > > +Y2038-proof @glibcadj{}.
> >
> > @glibcadj{} is incorrect here, this is not an adjective use.
>
> I would need a noun form here, and manual/macros.texi does not provide
> one. Should I add a @macro definition for glibcnoun there and use it in
> the paragraph above?
I think this paragraph would better be rewritten anyway, so avoiding the
need for a new macro.
Rather than writing the text as being about a change to glibc, and so
talking about "existing" symbols or object code and "newer" glibc, it
might better be written in terms of there being two kinds of glibc
configurations: those that only support 64-bit time_t, and those that
support both 32-bit and 64-bit time_t. (With a note, to be removed later,
that the latter are a work in progress, so that external interfaces for
64-bit time_t are not yet enabled on such configurations.)
Then you can explain that for the configurations with only 64-bit time_t,
there are no variant symbol names or function definitions for different
time_t choices (with the consequent internal #defines, etc.) - whereas on
configurations with both 32-bit and 64-bit time_t, time-related functions
generally have two definitions, one being a wrapper round the other (and
the symbol names not containing a "64" are the ones for 32-bit time_t).
This avoids needing to apply descriptions like "newer" or "Y2038-proof" to
"GNU C Library" (although such descriptions might still be relevant to
apply to functions).
With this structure, the fact that configurations with both 32-bit and
64-bit time_t are ones that used to have only 32-bit time_t is essentially
a historical note that explains why a particular design is used. At the
level of individual symbols, it may not even be true that one is the old
symbol and one is the new one; it's entirely plausible that new
time-related functions may be added after the 64-bit time_t support for
such platforms is complete (but before 32-bit time_t support is completely
obsoleted and the relevant symbols made into compat symbols), and so would
get both versions of the symbol added to glibc at the same time.
--
Joseph S. Myers
joseph@codesourcery.com