Re: CVS commit: src/lib/libc

[christos%astron.com@localhost (Christos Zoulas)]

In article <ZuH9e1qHreEvUUss%exadelic.gatalith.at@localhost>,
Thomas Klausner  <wiz%NetBSD.org@localhost> 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