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.
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.
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.
Rename compiler-warning-disable variables from
GCC_NO_warning
to
CC_WNO_warning
where warning is the full warning name as used by the compiler.
GCC_NO_IMPLICIT_FALLTHRU is CC_WNO_IMPLICIT_FALLTHROUGH
Using the convention CC_compilerflag, where compilerflag
is based on the full compiler flag name.
List all alternative forms recognized by string_to_flags(3).
Both "dump" and "nonodump" are the negative of "nodump".
string_to_flags does not recognize "snap".
Provide xrefs for flag descriptions where applicable.
Fix typos (2nd acst should have been acdt), 0550 for ist should be 0530
(5.5 hours is not 5 hours and 50 minutes...).
Comment out the zp4 zp5 and zp6 zone names. They are supposedly supported
by the source (they're in the table) but cannot work, as the parsedate
lexer doesn't allow a "word" to start with an alpha and also contain
digits. Maybe (just maybe) that could be fixed sometime, but since these
have never worked, and no-one has ever seemed to miss them, and they're the
only words which are of that form, for now, just stop pretending they work.
Add checks to detect overflow, and also detect other invalid
(out of range) inputs for parsedate().
There could be more, and some of what is being added is not
perfect, but many calculation overflows will be detected now
(and cause an error return) and some of the most bizarre
inputs that were previously accepted no longer will be.
before committing to it being an 8601 format date, rather than after
(or the fall back grammar parser doesn't start with a clean slate).
This isn't likely to ever bother anyone, the chances of encountering
something that looks just like an 8601 format date, but with a year
field so large it overflows a long are kind of slim. If it did happen
the chances that the string could be correctly parsed (into something
different) by the grammar are even slimmer. But better to do it properly.
ISO-8601 format yyyy-mm-ddTHH:MM:SS[radix_and+frac][Z]
be accepted.
We didn't handle that, as in parsedate(), 'T' represents the
military timezone designator, not a padding separator between
date & time as POSIX specified it.
The way parsedate() is written, fixing this in the grammar/lexer
would be hard without deleting support for T as a zone indicator
(it is *my* timezone!).
So, instead of doing that, parse an ISO-8901 string which occurs
right at the start of the input (not even any preceding white space)
by hand, before invoking the grammar, and so not involving the lexer.
This is sufficient to make touch -d conform.
After doing that, we still need to allow earlier valid inputs,
where an ISO-8601 format (using space as the separator, but without
the 'Z' (Zulu, or UTC) suffix) followed by an arbitrary timezone
designation, and other modifiers (eg: "+5 minutes" work. So we
call the grammar on whatever is left of the input after the 8601
string has been consumed. This all "just works" with one exception,
a format like "yyyy-mm-dd hh:mm:ss +0700" would have the grammar parse
just "+0700" which by itself would be meaningless, and so wasn't
handled. Add a grammar rule & processing to Handle it.
Also note that while POSIX specifies "at least 4" digits in the YYYY
field, we implement "at least one" so years from 0-999 continue to be
parsed as they always have (nb: these were, and continue to be, treated
as absolute year numbers, year 10 is year 10, not 2010). Years > 2 billion
(give or take) cannot be represented in the tm_year field of a struct tm,
so there's a limit on the max number of digits as well.
actual specific years, values from 69-99 be treated as 20th century,
and values from 0-68 be treated as 21st century. This allows for those
unfortunate enough to reside in a timezone west of Greenwich to convert
the epoch (or a time very close to it) to text, write that with just two
digits, and correctly convert it back to a time near the epoch, rather
than to something in 2069.
We used to split things so 0-69 were 21st century, and 70-99 were 20th.
Change that (this requires a change in the parsedate ATF tests which
test this specific boundary).
While here, add support for another POSIX requirement, that the radix
char before fractional seconds can be either a ',' or a '.'. We used
to allow only '.', add support for ','. This is something of a meaningless
change, as parsedate() returns a time_t in which there is no way to
represent fractional seconds, so there's little point in ever specifying
them regardless of what char is used for the "decimal point" - they will
be ignored anyway. But at least fractional seconds using a ',' as the
radix char will no longer cause the conversion to fail (or do something else
bizarre).
GCC_NO_FORMAT_TRUNCATION -Wno-format-truncation (GCC 7/8)
GCC_NO_STRINGOP_TRUNCATION -Wno-stringop-truncation (GCC 8)
GCC_NO_STRINGOP_OVERFLOW -Wno-stringop-overflow (GCC 8)
GCC_NO_CAST_FUNCTION_TYPE -Wno-cast-function-type (GCC 8)
use these to turn off warnings for most GCC-8 complaints. many
of these are false positives, most of the real bugs are already
commited, or are yet to come.
we plan to introduce versions of (some?) of these that use the
"-Wno-error=" form, which still displays the warnings but does
not make it an error, and all of the above will be re-considered
as either being "fix me" (warning still displayed) or "warning
is wrong."
The F spec is one of those, it should be terminated with \0 just like all
the others (irrelevant that it has no extra data to delimit).
Fix <sys/mman.h> to define the snprintb() format string correctly (include
the missing \0's). Fix the copy of that definition included into
snprintb(3) to match the updated mman.h version (ride the date bump
from the day before yesterday .. this is the same change, just corrected).
Undo the previous snprintb.c change ("off by one" fix) which was an
attempt to make the broken mman.h usage work (and did, but not the way
it should be done). Also, after using the new * format (instead of only
when something has already matched) skip the associated data so we don't
attempt to interpret it as more field specifiers. This func needs lots of TLC!
Fix the ATF tests for snprintb() to not assume that F format is really
exactly like f format, and has data after the field specifier. It doesn't.
Add several more tests (including testing the '*' field operator
recently added).
rillig