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 RFC 2] 02/63] Y2038: add function __difftime64


Hi Joseph,

On Wed, 18 Apr 2018 21:50:17 +0000, Joseph Myers
<joseph@codesourcery.com> wrote :

> On Wed, 18 Apr 2018, Albert ARIBAUD (3ADEV) wrote:
> 
> > diff --git a/time/Versions b/time/Versions
> > index fd838181e4..57314b98c8 100644
> > --- a/time/Versions
> > +++ b/time/Versions
> > @@ -65,4 +65,7 @@ libc {
> >    GLIBC_2.16 {
> >      timespec_get;
> >    }
> > +  GLIBC_2.27 {
> > +    __difftime64;
> > +  }  
> 
> Please send any such patches as appropriate for current master, which 
> means new symbols need to be at the version for the *next* release, 
> currently 2.28.

That's an overlook on my side; I'll bump up to 2.28.

> Each patch should avoid regressions, meaning that it should include 
> updates to all affected ABI baselines, unless there is a reason the series 
> would need to be squashed for commit (the series as a whole should also be 
> tested with build-many-glibcs.py).  Since there are no ABI baseline 
> updates whatever in the series byeond two librt.abilist files and two 
> libpthread.abilist files, but new ABIs are added to other libraries such 
> as libc, either the series is seriously broken or the claim of no test 
> regressions is incorrect.

The series is presented as a lot of small patches for clarity, with
only the final patch potentially modifying the public API (i.e., until
that patch, 'time_t' is always 32-bit, and only after the final patch
'time_t' /may/ be 32- /or/ 64-bit depending on _TIME_BITS). I expect
that the final series can and will be squashed indeed.

Re: test regressions: what I did was, on a target system, e.g. native
on an ARM system, to create two GLIBC trees, one with and one without
the patch set, configure them identically (except of course for the
build destination), run "make" and then run "make check" on both trees,
and compare the lists of errors, assuming that when the lists of errors
are the same there is no make check regression -- and then same for
'make xcheck'.

> As previously discussed, new ABI additions should be avoided for platforms 
> where time_t is already 64-bit.  Obviously testing on such platforms is 
> needed to make sure they continue to work just as they do now.

I'll add a 64-bit platform test on next run.

Cordialement,
Albert ARIBAUD
3ADEV


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