Hi Paul,
On Tue, 6 Nov 2018 16:28:36 -0800, Paul Eggert <egg...@cs.ucla.edu>
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 set.
> >
> > Any idea why?
>
> Either localtime_r is failing without setting errno so the bug is in
> localtime_r, or localtime_r never fails and so never sets errno so the
> bug is in mktime. Can you check which of these is happening?
I've instrumented the code while executing time/bug-mktime4.c. The
point where a failure result is returned without setting errno is at
line 442:
else if (--remaining_probes == 0)
return -1;
If I add a '__set_errno(EOVERFLOW);' under the else clause before the
'return -1;', then the test case runs fine. But I cannot set errno here
since I might overwrite a previous value set some time between
when mktime was entered and now.
So I have had a look at the functions involved in the for loop around
these lines: guess_time_tm and range_convert, to see how they handle
errno
From what I understand, guess_time_tm never fails as such. It may set
errno to EOVERFLOW, but that cannot explain the problem, which is the
opposite, i.e. failing without setting errno.
range_convert calls convert_time, which calls convert, which point to
localtime_r, which calls __tz_convert.
Of the three functions which __tz_convert calls, that is, __offtime,
__tz_compute, and __tzfile_compute, none fails without setting
errno.
(although I noticed that __tzfile_compute may call __tzstring which
might set errno, but __tzfile_compute returns void, so there's no
way for its caller to find out errno was set. But again, it is not the
type of issue we have here, which is errno *not* being set on failure.)
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 rounds it
allows itself.
I am instrumenting the code further to unravel the for probe loop
logic; anyone to whom this rings a bell is welcome to comment.
Cordialement,
Albert ARIBAUD
3ADEV
