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: Fifth draft of the Y2038 design document


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


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