C23 makes various standard library functions, that return a pointer into an input array, into macros that return a pointer to const when the relevant argument passed to the macro is a pointer to const. (The requirement is for macros, with the existing function types applying when macro expansion is suppressed. When a null pointer constant is passed, such as integer 0, that's the same as a pointer to non-const.) Implement this feature. This only applies to C, not C++, since such macros are not an appropriate way of doing this for C++ and all the affected functions other than bsearch have overloads to implement an equivalent feature for C++ anyway. Nothing is done to apply such a change to any non-C23 functions with the same property of returning a pointer into an input array. The feature is also disabled when _LIBC is defined, since there are various places in glibc that either redefine these identifiers as macros, or define the functions themselves, and would need changing to work in the presence of these macro definitions. A natural question is whether we should in fact change those places and not disable the macro definitions for _LIBC. If so, we'd need a solution for the places in glibc that define the macro *before* including the relevant header (in order in effect to disable the header declaration of the function by renaming that declaration). One testcase has #undef added to avoid conflicting with this feature and another has const added; -Wno-discarded-qualifiers is added for building zic (but could be removed once there's a new upstream tzcode release that's const-safe with this C23 change and glibc has updated to code from that new release). Probably other places in glibc proper would need const added if we remove the _LIBC conditionals. Another question would be whether some GCC extension should be added to support this feature better with macros that only expand each argument once (as well as reducing duplication of diagnostics for bad usages such as non-pointer and pointer-to-volatile-qualfied arguments). Tested for x86_64.
clang does not support the flag. Reviewed-by: Sam James <sam@gentoo.org>
Sync tzselect, zdump, zic to TZDB 2024a.
This patch incorporates the following TZDB source code changes,
listed roughly in descending order of importance.
zic now supports links to links, needed for future tzdata
zic now defaults to '-b slim'
zic now updates output files atomically
zic has new options -R, -l -, -p -
zic -r now uses -00 for unspecified timestamps
zdump now uses [lo,hi) for both -c and -t
Fix several integer overflow bugs
zic now checks input bytes more carefully
Simplify and fix new TZDIR setup
Default time_t to 64 bits on glibc 2.34+ 32-bit
zic now generates TZ strings that conform to POSIX when all-year DST
zic -v now shows extreme-int tm_year transitions
Fix zic bug in last time type of Asia/Gaza etc.
Fix zic bug with Palestine after 2075
Fix bug uncovered by recent change to Iran history
Fix 'zic -b fat' bug with Port Moresby 32-bit data
Fix zic bug with -r @X where X is deduced from TZ
Fix bug with zic -r cutoff before 1st transition
Fix leap second expiry and truncation
Fix zic bug on Linux 2.6.16 and 2.6.17
Fix bug with 'zic -d /a/b/c' if /a is unwriteable
Don't mistruncate TZif files at leap seconds
Fix zdump undefined behavior if !USE_LTZ
zdump -v reports localtime+gmtime failures better
Fix zdump diagnostic for missing timezone
Don't assume nonempty argv
Port better to C23
Do not assume negative >> behavior
I18nize zdump a bit better
Port zdump to right_only installations
New tzselect menu option 'now'
tzselect can now use current time to help choose
Improve tzselect behavior for Turkey etc.
tzselect: do not create temporary files
tzselect: work around mawk bug with {2,}
tzselect: Port to POSIX awk, which prohibits -v newlines
Do not use empty RE in tzselect
Don't set TZ in tzselect
Avoid sed, expr in tzselect
tzselect: Fix problems with spaces in TZDIR
Improve tzselect diagnostics
Remove zic workaround for Qt bug 53071
Remove zic support for "min" in Rule lines
Remove zic support for zic -y, Rule TYPEs, pacificnew
Remove tzselect workaround for Bash 1.14.7 bug
* SHARED-FILES: Update to match current sync.
* config.h.in (HAVE_STRERROR): Remove; no longer needed.
* timezone/Makefile ($(objpfx)zic.o): Depend on tzdir.h.
($(objpfx)tzdir.h): New rule to build a placeholder.
* timezone/private.h, timezone/tzfile.h, timezone/version:
* timezone/zdump.c, timezone/zic.c: Copy verbatim from TZDB 2024a.
The daylight variable is supposed to be set to 1 if DST is ever in use for the current time zone. But __tzfile_read used to do this: __daylight = rule_stdoff != rule_dstoff; This check can fail to set __daylight to 1 if the DST and non-DST offsets happen to be the same.
The $(testdata)/XT5 rule is ambiguous and it may not be correct evaluated.
I used these shell commands: ../glibc/scripts/update-copyrights $PWD/../gnulib/build-aux/update-copyright (cd ../glibc && git commit -am"[this commit message]") and then ignored the output, which consisted lines saying "FOO: warning: copyright statement not found" for each of 7061 files FOO. I then removed trailing white space from math/tgmath.h, support/tst-support-open-dev-null-range.c, and sysdeps/x86_64/multiarch/strlen-vec.S, to work around the following obscure pre-commit check failure diagnostics from Savannah. I don't know why I run into these diagnostics whereas others evidently do not. remote: *** 912-#endif remote: *** 913: remote: *** 914- remote: *** error: lines with trailing whitespace found ... remote: *** error: sysdeps/unix/sysv/linux/statx_cp.c: trailing lines
This test-case is the tzfile for Asuncion generated by tzlib-2021e as follows, using the tzlib-2021e zic: "zic -d DEST -r @1546300800 -L /dev/null -b slim SOURCE/southamerica". Note that in its type 2 header, it has two entries in its "time-types" array (types), but only one entry in its "transition types" array (type_idxs). * timezone/Makefile, timezone/tst-pr28707.c, timezone/testdata/gen-XT5.sh: New test. Co-authored-by: Christopher Wong <Christopher.Wong@axis.com>