This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]