Fifth draft of the Y2038 design document

[Albert ARIBAUD]

Hi Joseph,

On Wed, 8 Mar 2017 20:11:24 +0000, Joseph Myers
<joseph@codesourcery.com> wrote :

> On Wed, 8 Mar 2017, Albert ARIBAUD 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'.  
> 
> 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;

and since (at least in gcc) REDIRECT(name,proto,alias) ends up declaring
symbol 'name' with an 'asm(alias)' clause, it follows that compiling
a .c file referring to 'clock_gettime' produces an intermediate .s file
where occurrences of 'clock_gettime' are replaced with '__clock_gettime'
and therefore produces a .o file which *does* reference __clock_gettime.

So yes, the .c file does not reference __clock_gettime; but the .o
file does.

Or do I miss something?

Cordialement,
Albert ARIBAUD
3ADEV