[Bug 276281] lang/python39 fails to include tzset in time module
- In reply to: bugzilla-noreply_a_freebsd.org: "[Bug 276281] lang/python39 fails to include tzset in time module"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
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.