In article <zuh9e1qhreevu...@exadelic.gatalith.at>, Thomas Klausner <w...@netbsd.org> wrote: >On Wed, Sep 11, 2024 at 09:50:35AM -0400, Christos Zoulas wrote: >> Module Name: src >> Committed By: christos >> Date: Wed Sep 11 13:50:35 UTC 2024 >> >> Modified Files: >> src/lib/libc/compat/time: compat_localtime.c >> src/lib/libc/time: CONTRIBUTING Makefile Makefile.inc NEWS asctime.c >> localtime.c private.h theory.html tz-art.html tz-link.html tzfile.5 >> tzselect.ksh version zdump.c zic.8 zic.c >> >> Log Message: >> Merge tzcode-2024b >> >> Release 2024b - 2024-09-04 12:27:47 -0700 >> >> Changes to code >> >> localtime.c now always uses a TZif file's time type 0 to handle >> timestamps before the file's first transition. Formerly, >> localtime.c sometimes inferred a different time type, in order to >> handle problematic data generated by zic 2018e or earlier. As it >> is now safe to assume more recent versions of zic, there is no >> longer a pressing need to fail to conform RFC 8536 section 3.2, >> which requires using time type 0 in this situation. This change >> does not affect behavior when reading TZif files generated by zic >> 2018f and later. >> >> POSIX.1-2024 removes asctime_r and ctime_r and does not let >> libraries define them, so remove them except when needed to >> conform to earlier POSIX. These functions are dangerous as they >> can overrun user buffers. If you still need them, add >> -DSUPPORT_POSIX2008 to CFLAGS. > >Hm, that sounds like we should hide asctime_r and ctime_r? >
I think that it will break stuff in pkgsrc... We could, I guess. christos
