On Wed, 14 Nov 2018 00:04:04 +0100, Albert ARIBAUD
wrote :
> If I can get
> the adequate permissions for Bugzilla.
... I'll push the series onto master.
Cordialement,
Albert ARIBAUD
3ADEV
Hi Paul,
On Fri, 9 Nov 2018 18:00:25 -0800, Paul Eggert
wrote :
> On 11/7/18 6:48 AM, Albert ARIBAUD wrote:
>
> > 1. If the for-loop reaches remaining_probes==0, then it really should
> > set errno = EOVERFLOW before returning -1, because remaining_probes
> > is
On Wed, 7 Nov 2018 13:39:42 +0100, Albert ARIBAUD
wrote :
> So it seems to me that we're really "just" reaching a maximum of probes
> after which __mktime_internal, while not failing at computing candidate
> times, could not find a perfect match in less than the 6 r
Hi Paul,
On Tue, 6 Nov 2018 16:28:36 -0800, Paul Eggert
wrote :
> On 11/6/18 12:41 PM, Albert ARIBAUD wrote:
> > Issue is that __mktime_internal exited through
> >
> > else if (--remaining_probes == 0)
> >return -1;
> >
> > with errno never s
Hi Paul,
On Tue, 6 Nov 2018 06:43:06 +0100, Albert ARIBAUD
wrote :
> Hi Paul,
>
> On Sun, 4 Nov 2018 23:54:59 -0800, Paul Eggert
> wrote :
>
> > Paul Eggert wrote:
> > > 3. Please construct a third patch containing your mktime test case for
> > > gli
h your patches applied there are still paths which
yield "mktime failed without setting errno" when make check is run for
i686-linux-gnu. I'll go through the call path and see where it fails.
Cordialement,
Albert ARIBAUD
3ADEV
Hi Paul,
(sorry for the long delay)
Le Wed, 1 Aug 2018 23:45:08 -0700, Paul Eggert
a écrit :
> Albert ARIBAUD wrote:
> > I really need you to develop in some more detail how you envision adding
> > Y2038 support in Gnulib.
>
> It sounds like the best thing to do is t
Hi Paul,
Le Wed, 1 Aug 2018 11:49:39 -0700, Paul Eggert a
écrit :
> Albert ARIBAUD wrote:
> > Hm... I fear that there's a vicious circle here: Paul wants Y2038
> > support code to go into Gnulib before it goes to glibc (for that part
> > of the code which exists in bo
to break the vicious
circle.
> I considered doing a similar thing with wchar_t on Windows platforms
> (define a 32-bit wchar_t where the system one is only 16-bit), but gave
> up, facing the huge complexity.
I've got a 60-odd patch list for glibc at the moment, and I probably
haven't covered everything, but at least it is self-contained. I fear
the problem is going to get one order of magnitude more complex by
introducing ordering dependencies between gnulib and glibc.
> Bruno
Cordialement,
Albert ARIBAUD
3ADEV
Sorry, hit the enter key way earlier that I should have.
Le Wed, 1 Aug 2018 11:49:49 +0200, Albert ARIBAUD
a écrit :
> Hi Paul,
>
> Le Fri, 6 Jul 2018 21:45:54 -0700, Paul Eggert a
> écrit :
>
> > Bruno Haible wrote:
> > > What would be the benefit of doing so
onsider the simple fact of
having a Y2038-proof time representation.
Cordialement,
Albert ARIBAUD
3ADEV
Bonjour Paul,
Le Thu, 5 Jul 2018 12:45:30 -0700, Paul Eggert a
écrit :
> Albert ARIBAUD wrote:
>
> > Since gnulib is on Savannah, not Sourceware, I assume I will need to be
> > given some level of write access to the Savannah gnulib repository in
> > order to pr
Hi Bruno,
Le Thu, 05 Jul 2018 23:17:26 +0200, Bruno Haible a
écrit :
> Albert ARIBAUD wrote:
> > I was under the impression that you wanted the
> > 64-bit-time stuff to go in gnulib before it went in glibc, so I don't
> > get what the "once glibc has such a mac
Hi Paul,
On Thu, 5 Jul 2018 12:40:07 -0700, Paul Eggert
wrote :
> Albert ARIBAUD wrote:
> > I would like to know
> > if the following assumptions are correct:
> >
> > - gnulib contains a year2038 module which is only intended to check
> >whether
Hello all,
On Wed, 27 Jun 2018 13:03:42 +0200, Albert ARIBAUD
wrote :
> Hi Paul,
>
> On Mon, 25 Jun 2018 16:56:14 -0700, Paul Eggert
> wrote :
>
> > On 06/25/2018 03:32 PM, Albert ARIBAUD wrote:
> > > I replaced the original 32-bit difftime with a wrapper
>
15 matches
Mail list logo
