Always null-terminate the output in the buffer, even in error cases. The
wording in the manual page has been promising this since 2008. For
snprintb_m, ensure that the output is terminated with two null
characters, to gracefully handle situations in which the caller does not
check whether snprintb returned an error.
If the buffer size is zero, allow the buffer to be a null pointer,
analogous to snprintf.
Fix an out-of-bounds memory read if the bitfmt ends with a '*' directive
(since today).
In the tests, merge the helper functions for snprintb, snprintb_m, as
they were similar enough.
Fix a few 'line_max exceeded' tests, ensuring that they output a '#'
marker, and that the 'complete' tests don't.
Previously, these invoked undefined behavior, now they lead to an early
return. An example of out-of-bounds bit number is in SCZ_PCICTRL_BITS.
Bit fields that extend beyond the msb are still allowed.
Allow 'f' and 'F' to have fields that are 64 bits wide. This only makes
sense when the field starts at bit 0.
Remove the unused 'val_len', it was only needed before snprintb.c 1.20.
strftime %s now uses tm_gmtoff if available. (Problem and draft
patch reported by Dag-Erling Smørgrav.)
of the tzcode2924a update. It is bogus. The "problem" is/was a simple
misunderstanding of what strftime(%s) is intended to output. The "fix"
breaks it.
Release 2024a - 2024-02-01 09:28:56 -0800
Changes to code
The FROM and TO columns of Rule lines can no longer be "minimum"
or an abbreviation of "minimum", because TZif files do not support
DST rules that extend into the indefinite past - although these
rules were supported when TZif files had only 32-bit data, this
stopped working when 64-bit TZif files were introduced in 1995.
This should not be a problem for realistic data, since DST was
first used in the 20th century. As a transition aid, FROM columns
like "minimum" are now diagnosed and then treated as if they were
the year 1900; this should suffice for TZif files on old systems
with only 32-bit time_t, and it is more compatible with bugs in
2023c-and-earlier localtime.c. (Problem reported by Yoshito
Umaoka.)
localtime and related functions no longer mishandle some
timestamps that occur about 400 years after a switch to a time
zone with a DST schedule. In 2023d data this problem was visible
for some timestamps in November 2422, November 2822, etc. in
America/Ciudad_Juarez. (Problem reported by Gilmore Davidson.)
strftime %s now uses tm_gmtoff if available. (Problem and draft
patch reported by Dag-Erling Smørgrav.)
Changes to build procedure
The leap-seconds.list file is now copied from the IERS instead of
from its downstream counterpart at NIST, as the IERS version is
now in the public domain too and tends to be more up-to-date.
(Thanks to Martin Burnicki for liaisoning with the IERS.)
Changes to documentation
The strftime man page documents which struct tm members affect
which conversion specs, and that tzset is called. (Problems
reported by Robert Elz and Steve Summit.)
- Mention that the 'fmt' argument to these functions holds
a printf(3)-like format specification.
- Clarify that the err()/warn()/errc()/warnc() family of functions
will append an additional error message to the output.
- Add whitespace to separate paragraphs describing distinct
concepts.
- Move the sentence mentioning the final output newline to
a less ambiguous location within the text.
- Add a cross-reference to printf(3).
In the examples using hex escape sequences, there must be a delimiter
between the escape sequence and the following description if the
description starts with [A-Fa-f], as hex escape sequences are not
limited in length.
Distinguish between a 'directive' (bit + length + description) and a
'description' (only the text).
The fmt parameter is not a string, as strings only reach to the first
'\0' byte, but the new-style format may include additional '\0' as bit
numbers.
While here add a commment about how the __i386__ magic LD80C macro
might no longer work on all other arch's as well (if someone can verify
that it still does, or can fix it so that it still works on i386, but
also works everywhere else, then please remove that XXX comment.
The issue I am (perhaps imagining) is the (uint32_t) cast.
amd64 port build again after the long double math function infusion
from yesterday.
Feel free (without consulting me, I'm just hacking about) to revert
any of this and do it a better way.
Note: this is not intended to be complete, in particular, in <math.h>
I added prototypes only for the functions that are needed for a
successful build, not all of the new ones...
Restore the empty string at the end of snprintb_m output that was
accidentally removed along with empty string placeholders in the
format strings. While here, move that example to be next to its
snprintb counterpart.
Bring over the prettier version of the mmap format string that we have
in the header file for some time now. Clarify that the final NUL of
the new format string is supplied by the compiler, g/c explicit final
\0 from the example that had it.
Try to make the narration more coherent. Make the old and new
syntaxes easy to distinguish and go out of our way to highlight that
the old syntax uses 1-based bit positions.
The first example broke the format string at boundaries that didn't
highlight the structure of the format string and also didn't make it
clear that a few bits were omitted from having descriptions.
The second example contained an off-by-one error for SIXTEEN, which was
actually FIFTEEN.
The snprintb_m example repeated the above off-by-one error, and its
output was shown wrong, due to concatenated escape sequences.
christos