[Bug 276281] lang/python39 fails to include tzset in time module

From: <bugzilla-noreply_at_freebsd.org>
Date: Sun, 11 Feb 2024 21:11:50 UTC
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276281

Maxim Dounin <mdounin@mdounin.ru> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mdounin@mdounin.ru

--- Comment #11 from Maxim Dounin <mdounin@mdounin.ru> ---
This seems to be a bug in tzcode, as recently updated from tzcode2010m to
tzcode2023c. The bug is still present upstream, checked most recent tzcode2024a
and github.

More specifically, the tzparse() function in localtime.c uses the
increment_overflow_time() function, assuming that the resulting variable
("janfirst" variable) is not changed when the overflow is detected:

https://github.com/eggert/tz/blob/e48c5b532a26e094db24a7de44c33786860c7ae1/localtime.c#L1187

This assumption, however, is not true if increment_overflow_time() is
implemented using C23 ckd_add() or __builtin_add_overflow(): the overflowed
result is stored to the variable instead. This manifests itself on systems with
32-bit time_t, where the loop in question reaches the overflow.

The most trival workaround I can see would be to compile localtime.c with
HAVE_STDCKDINT_H defined to 0, so that C implementation of
increment_overflow_time() is used instead of __builtin_add_overflow(). The C
implementation does not change the resulting variable on overflow, so the
assumption of the code holds true.

Here is a simple test with the most recent tzcode sources, tzcode2024a, on
FreeBSD 13.2-RELEASE-p8 i386:

$ make date
cc  -O2 -pipe -c date.c -o date.o
printf '%s\n' >tzdir.h.out  '#ifndef TZDEFAULT'  '# define TZDEFAULT
"/etc/localtime" /* default zone */'  '#endif'  '#ifndef TZDIR'  '# define
TZDIR "/usr/share/zoneinfo" /* TZif directory */'  '#endif'
mv tzdir.h.out tzdir.h
cc  -O2 -pipe -c localtime.c -o localtime.o
cc  -O2 -pipe -c strftime.c -o strftime.o
cc  -O2 -pipe -c asctime.c -o asctime.o
cc -o date -O2 -pipe  date.o localtime.o strftime.o asctime.o 
$ TZ=AEST-10AEDT-11,M10.5.0,M3.5.0 ./date -r 1044144000
Sun Feb  2 10:00:00 AEST 2003

As can be seen from "10:00:00 AEST", the result is broken. The same code,
recompiled with HAVE_STDCKDINT_H set to 0:

$ touch localtime.c
$ make date CFLAGS=-DHAVE_STDCKDINT_H=0
cc  -DHAVE_STDCKDINT_H=0 -c localtime.c -o localtime.o
cc -o date -DHAVE_STDCKDINT_H=0  date.o localtime.o strftime.o asctime.o 
$ TZ=AEST-10AEDT-11,M10.5.0,M3.5.0 ./date -r 1044144000
Sun Feb  2 11:00:00 AEDT 2003

Now the result is correct, "11:00:00 AEDT".

It would be great if someone can take a look and implement a workaround.

-- 
You are receiving this mail because:
You are the assignee for the bug.