glibc bug 23789 (was: [PATCH v3] Y2038: make __mktime_internal compatibles with __time64_t)

[Albert ARIBAUD]

On Wed, 24 Oct 2018 13:23:18 +0200, Albert ARIBAUD
<albert.aribaud@3adev.fr> wrote :

> Also, I assume tests would be needed for both cases where
> __mktime_internal() returns -1? If so, I would need struct tm values
> which trigger either one, or at least indications on how to find ones.

Regarding the tests:

There are already four mktime test files used by 'make check':

	time/tst-mktime.c
	time/bug-mktime1.c
	time/tst-mktime2.c
	time/tst-mktime3.c

If I am getting the logic right, I should not extend any of these files,
but rather, I should add a new file, e.g.:

	time/bug-mktime4.c

which would essentially be an adaptation of the test file attached by
Paul to the bugzilla entry:

https://sourceware.org/bugzilla/attachment.cgi?id=11343

BTW: Paul, your program returns 2 when errno is not EOVERFLOW, but 2 is
not supported as an EXIT_* value, only 0 (EXIT_SUCCESS), 1
(EXIT_FAILURE) and 77 (EXIT_UNSUPPORTED). I assume that was an ad hoc
choice to distinguish the "errno is not EOVERFLOW" failure from a
hypothetical "mktime did not return -1" failure. Within the glibc test
framework, I suspect we would return 1 / EXIT_FAILURE for both, and
print the detailed failure reason on stdout.

I am not entirely sure about the 'bug-' vs 'tst-' prefix, though; I
assumed that since we have a BZ id for the problem, it should be
'bug-', but does it work that way?

And one last question: should I not first commit the test (and with make
check on a 32-bit architecture, show that it adds one FAIL) then commit
the fix (and show with the same make check that the FAIL disappears)?

Cordialement,
Albert ARIBAUD
3ADEV