Paul Eggert wrote:
0001 and 0002 ... could be
installed into Glibc now too, as they are independent of your Y2038 changes,
I reworked those two patches as standalone against glibc and filed a bug report
as glibc Bug#23603. See:
https://sourceware.org/bugzilla/show_bug.cgi?id=23603
With thi
Eli Zaretskii wrote:
A nit: it should be okay to require C99 for the compiler, but we
should not require that for the library (including header files),
because MinGW, for example, uses a C99-compliant GCC, but the headers
and the function from the standard C library are those from Windows,
which
Albert ARIBAUD wrote:
https://sourceware.org/git/?p=glibc.git;a=shortlog;h=refs/heads/aaribaud/y2038
Thanks for the heads-up. I would like to look at these patches sequentially.
Let's start with the first three:
Y2038: Add 64-bit time for all architectures
Y2038: make __tz_convert compatible
* lib/mktime.c, lib/timegm.c (mktime_offset_t) [_LIBC]:
Now long int, not time_t, since long int is the longstanding type
for this in glibc and there is no need to change it even if time_t
becomes 64 bits - even int would do, though this would be a change
to the glibc generated code. When this cha
Move code around to make a merge to glibc easier to audit.
This should not change behavior.
* lib/mktime.c: Include more standard files unconditionally.
(NEED_MKTIME_INTERNAL, NEED_MKTIME_WINDOWS)
(NEED_MKTIME_WORKING): Give default values to pacify -Wundef,
which glibc uses. Default NEED_MKTIME_W
> From: Tom Tromey
> Cc: Tom Tromey , Bruno Haible , Paul
> Eggert , bug-gnulib@gnu.org, gdb-patc...@sourceware.org
> Date: Sat, 01 Sep 2018 00:05:26 -0600
>
> Sergio> I don't know if just requiring C99 or later would be enough to solve
> Sergio> this problem, but it's something to consider
