Re: Fifth draft of the Y2038 design document

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

Hi Zack,

On Wed, 8 Mar 2017 08:35:30 -0500, Zack Weinberg <zackw@panix.com>
wrote :

> On Wed, Mar 8, 2017 at 7:27 AM, Albert ARIBAUD <albert.aribaud@3adev.fr> wrote:
> >
> > Assume one single source file (say, app.c) which includes <time.h> and
> > refers to 'clock_gettime'. This source code is compiled into two object
> > modules, one with -DTIME_BITS=64 (sayn app64.o) and one without (say,
> > app32.o). Both object modules expect to be linked and run against the
> > (same) GLIBC dynamic library. For the app32.o module, we expect its
> > call to 'clock_gettime' to end up executing '__clock_gettime' while for
> > the app64.o module, we expect its 'clock_gettime' call to end up
> > executing '__clock_gettime64'.
> >
> > My question is, how exactly can the GLIBC API make app32.o use
> > '__clock_gettime' and app64.o use '__clock_gettime64' when app.c refers
> > to 'clock_gettime'?  
> 
> This is what the __REDIRECT macros are for.  Look at the existing
> logic in the headers that handles __USE_FILE_OFFSET64: for instance,
> in unistd.h
> 
> #ifndef __USE_FILE_OFFSET64
> extern __off_t lseek (int __fd, __off_t __offset, int __whence) __THROW;
> #else
> # ifdef __REDIRECT_NTH
> extern __off64_t __REDIRECT_NTH (lseek,
>                                  (int __fd, __off64_t __offset, int __whence),
>                                  lseek64);
> # else
> #  define lseek lseek64
> # endif
> #endif
> 
> (The fallback to #define hasn't been tested in at least a decade and
> there's an argument for scrapping it.)

> zw

Ah, __REDIRECT wraps the aliased name with an 'asm', so in my example,
the app32.o and app64.o object modules will refer to __clock_gettime
and __clock_gettime64' respectively when their (common) source refers
toclock_gettime, all without needing to include declarations for
__clock_gettime or __clock_gettime64.

Thanks!

Cordialement,
Albert ARIBAUD
3ADEV