Re: Fifth draft of the Y2038 design document

[Albert ARIBAUD <albert dot aribaud at 3adev dot fr>]

Hi Joseph,

On Thu, 9 Mar 2017 21:26:16 +0000, Joseph Myers
<joseph@codesourcery.com> wrote :

> On Thu, 9 Mar 2017, Albert ARIBAUD wrote:
> 
> > > As I said above, no user .o file should ever end up referencing 
> > > __clock_gettime; that's a purely internal symbol, not a public ABI.  
> > 
> > Well, in time/time.h, clock_gettime" is defined in time/time.h by
> > 
> > 	extern int __REDIRECT(clock_gettime, (clockid_t __clock_id,
> > 	  struct timespec *__tp), __clock_gettime) __THROW;  
> 
> No, it's not, in master (and that line is badly formatted in other ways).
> Any change on a branch that introduces such a declaration is an incorrect 
> change.

My bad -- that's something I had introduced in my Y2038 experimental
branch based on uses of __REDIRECT I'd misinterpredted. Somehow I had
wrongly turned the requirement of having only one clock_gettime at
source level into "having only one API symbol and associating it with
either one of two implementations", instead of "having a single source
level symbol associated to either one of two API symbols, and then
associating each API symbol to one corresponding implementation".

So I suspect the following, inspired from e.g. the scandir example, is
what should be put in time/time.h:

#ifndef __USE_TIME_BITS64
extern int clock_gettime (clockid_t __clock_id, struct timespec *__tp) __THROW;
#else
# ifdef __REDIRECT
extern int __REDIRECT(clock_gettime,(clockid_t __clock_id, struct timespec *__tp),clock_gettime64) __THROW;
# else
#  define clock_gettime clock_gettime64
#endif

And then, in GLIBC's sysdeps/unix/clock_gettime.c (or possibly in a new
sysdeps/unix/clock_gettime64.c), add a

	weak_alias(__clock_gettime64,clock_gettime64)

to the already existing weak_alias(__clock_gettime,clock_gettime).

In the 64-bit time case, this mechanism does defines a symbol at API
source level which is represented by another at object level, but at
least it aliases two API symbols, rather than aliasing an API and an
implementation symbol on the API side.

Cordialement,
Albert ARIBAUD
3ADEV