Repurpose message 362, as the previous version was redundant since null
bytes in old-style formats are already covered by message 371 (bit
position out of range) and 377 (redundant '\0' at the end).
The functions snprintb and snprintb_m are specific to NetBSD, and their
format strings are tricky to get correct. Provide some assistance in
catching the most common mistakes.
Always write the value to be formatted in hexadecimal, to make it easily
distinguishable from the buffer size and maximum line length.
Use consistent wording in the comments of the test cases. Be stricter
about mistakes in a format.
Fix some wrong numbers in the snprintb_m tests for limited line length.
Previously, these descriptions were only allowed on platforms where
plain 'char' is unsigned. On platforms where plain 'char' is signed,
they invoked undefined behavior or terminated the output early.
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.
The manual page promises that the 'max' argument limits the length of
the generated strings, so don't generate any strings that are longer
than that limit. Mark incomplete strings with a trailing '#' to make
them easily recognizable.
Before t_snprintb.c 1.20, the buffer size was required to be greater
than zero. Allowing the buffer size to be zero led to buf[-1] being
checked. On amd64, that byte happened to be 0, on i386 it didn't.
Fixes PR lib/57951.
longjmp evidently doesn't reset the state of whether the process is
executing on the alternate signal stack. So when we re-enter the
signal handler, the alternate stack appears to be still in use, and
the system chooses the original stack for the second call to the
signal handler -- which trips our assertion asking to verify that the
signal handler is always using an alternate stack.
Not strictly necessary for the signal handler to use an alternate
stack on re-entry, but this makes it clearer that the signal handler
itself is always using the alternate stack so we can verify that the
interrupted code is _not_ in the signal handler.
With this change, the test now passes on aarch64.
PR lib/57946
But only by code inspection; it appears to have another problem: on
re-entry, the signal handler is called on the normal stack, not on
the alternate signal stack.
PR lib/57946
Due to the check that any bytes beyond the expected output must be
unmodified, there's no need anymore to explicitly write the "ZZZ" at the
end of the expected output. While here, remove the redundant trailing
"\0".
Add more tests to cover possible situations where an out-of-bounds write
may have occurred. In some cases, the line length specified in
snprintb_m is exceeded.
In the previous commit, I had accidentally only run the tests for
snprintb_m but not those for snprintb, thereby missing a newly
introduced bug that would not null-terminate the resulting strings.
Add more tests to cover similar situations in which the buffer is too
small to contain the complete output.
The debug output contained too many newlines.
The buffer functions were built into lint2 even though they weren't
used.
Enable the query for invisible characters in string literals, to make
sure that a newline in a string literal does not trigger that query.
For now, the chronologic order is not enforced but has to be established
manually, for example by removing all 'expect' comment lines and
regenerating them with 'accept.sh -u'.
While here, clean up a few instances that came up when regenerating the
'expect' comments, such as wrong indentation or needless deviation from
the 'expect+1' form.
Test all number bases (octal, decimal, hexadecimal), in both old-style
and new-style formats, as well as small buffer sizes.
Document working edge cases such as empty descriptions or descriptions
containing spaces, as well as situations that invoke undefined behavior.
Add comments to the individual test cases, as reading the actual format
strings takes more time.
In case of a failure, print the details of the test case, including file
and line number of the actual test data. Do not write the format strings
directly to the output, as they contain non-printable bytes and embedded
null bytes.
After a failed test case, continue with the others.
Lay out the format strings according to their structure, to make them
more readable. Remove redundant "\0" at the end of the new-style format
strings.
Fix an off-by-one error in the test data: 0xf is FIFTEEN, not SIXTEEN.
Add a test for performing a restricted subset of rot13 in the format
string, to explore the limits of snprintb formatting.
What's still missing are tests for edge cases and error cases.
Except etc and xetc, which likely won't match for reasons that aren't
great, like etc including empty log files which in an installed
system have probably changed.
This test will probably fail, but we should make sure it doesn't!
PR misc/57877
It was confusing to have two kinds of "symbol type" (s_type and s_symt),
so rename all related identifiers to be more distinctive.
No functional change.
Both GCC 11 and Clang 8 accept member-designators that are not
identifiers but designator sequences, such as in 'offsetof(struct stat,
st_atim.tv_sec)', so make lint accept them as well.
Plain integer constants without suffix are first tried to fit into
'int', then 'long', but not 'long long'. This means that numbers larger
than 32 bits must be written with the LL suffix.
Previously, the expression 'a & b' was only treated as bool if 'a' had
enum type. This didn't cover cases in which bit masks were implemented
using integer types instead of enum sets.
Unknown escape sequences in string literals trigger an error, since
testlang_conf.l 1.22 from 2021-02-25.
The '\b' is recognized since testlang_conf.l 1.26 from 2021-11-15.
Tested this on i386 since that had been crashing before, but i386
doesn't see %zu for unsigned int as a problem.
PR lib/57721
XXX pullup-10
XXX pullup-9
XXX pullup-8
The jmp_buf is not, in fact, uninitialized at the point of use, but
it doesn't hurt to narrow the scope a bit to between when the jmp_buf
is initialized by setjmp, and when the signal handler might be called
after sigaction.
Noted by prlw1.
PR lib/57721
XXX pullup-10
XXX pullup-9
XXX pullup-8
Make sure to allocate enough space for the thread's stack for a guard
even though there shouldn't be one, so that when we run the thread,
it doesn't start with the stack pointer pointing into someone else's
allocation (like malloc) causing stack frames to trash another data
structure -- or causing the user of that data structure to trash the
stack frames.
PR lib/57721
XXX pullup-10
XXX pullup-9
XXX pullup-8
Use
ATF_REQUIRE_EQ_MSG(dlinfo(...), 0, "dlinfo: %s", dlerror())
instead, in order to accurately report the error on failure. RZ is
only for functions like pthread_create(3) that return zero on success
and errno(3) code on failure, but dlinfo returns -1 on failure and
sets dlerror() to report the nature of the error.
RZ succeeds if x is zero, and fails if x is nonzero, treating a
nonzero value as a error number as in errno(3) to print the message.
The following library routines instead return -1 on failure and set
errno to the error code:
fuse_opt_add_arg
fuse_opt_add_opt
fuse_opt_add_opt_escaped
fuse_opt_insert_arg
lseek
system
So use RL instead for those -- succeeds if x is zero, and fails if x
is -1.
This shouldn't make any tests newly fail or newly succeed -- the
functions in question only ever return 0 or -1 -- but if the tests
were already failing anywhere, they will now fail with meaningful
messages.
TBD: dlinfo, which isn't fit for RL or RZ since it reports errors via
dlerror() rather than errno.
Not likely to matter, but in the unlikely event that rump_sys_close
fails, it will return -1 and set errno as RL expects, not return the
error code as RZ expects.
Print the correct input, and print the rounding mode for clarity so
you don't have to cross-reference it by line number.
PR port-mips/57680
XXX pullup-10
Except gcc doesn't implement this pragma, so make it conditional.
And clang only supports it on some architectures, so just leave it
out for now with a comment about why.
PR port-mips/57680
XXX pullup-10
At least for addition operations, anyway.
Somewhat redundant with the test t_fe_round added by maya@ but this
gives two minimal pairs to easily diagnose exactly what the rounding
mode is when the wrong one was selected.
PR port-mips/57680
XXX pullup-10
The test modifies if_capabilities for all available interfaces.
This is not a behavior we expect for normal ATF runs.
Similar tests modifying living network configurations are already
skipped by default. This is the last one remained for ifconfig(8).
Also, I'm not sure whether this is a test for ifconfig(8).
XXX
Pullup to netbsd-10 ASAP. No other branches are affected.
For the write test, need to make sure the pipe's buffer is full first
before the write that blocks, so that it doesn't return partial
progress rather than ERESTART if woken.
(some) removing of quotes from where they're useless (superstition).
This should be NFC for these tests, as the data being quoted doesn't
happen to require it, but depending upon the data not altering, or the
code not being copied to a different environment is unwise, when it is
so easy to simply do it correctly.
A few line wrapping and white space changes as well.
Nothing changed here is intended to alter the way that the tests run,
or results generated.
and carp_handover_ipv6_ifdown_nocarpdevip test cases to fail. At
least on the TNF i386 and amd64 testbeds, they pass more often than
not since the commit of src/sys/netinet/ip_carp.c 1.119 by mlelstv on
2023.04.07.06.44.08.
Previously, in a '?:' expression with a constant condition, the branch
that is not taken was skipped but any identifiers in there were intended
to be marked as used. In function call expressions, this only worked
for the last argument, as the PUSH operator is not a binary operator
(see ops.def). Cover this case as well.
While here, write it atomically: write to .tmp first, then rename
when done; this way applications never see a partially-written bundle
at /etc/openssl/certs/ca-certificates.crt.
there's a clearly initialised memory region that is claimed as
being maybe uninitialised, and this test-build version of it
triggers it while the normal build doesn't.
Also avoid clobbering some other edge cases like symlinks or
non-directories there.
This way, we have the following transitions on system updates:
- If /etc/openssl/certs is empty (as in default NetBSD<10 installs):
quietly populated on rehash.
- If /etc/openssl/certs is nonempty (you've added things to it,
e.g. by hand or with mozilla-rootcerts) and has never been managed
by certctl(8): left alone on rehash, with an error message to
explain what you need to do.
- If /etc/openssl/certs has been managed by certctl(8): quietly
updated on rehash.
Note: This means current installations made since certctl(8) was
added will be treated like /etc/openssl/certs is nonempty and has
never been managed by certctl(8). To work around this, you can just
delete /etc/openssl/certs and rerun `certctl rehash'.
This is the scenario when you have previously populated
/etc/openssl/certs manually, or with a package like mozilla-rootcerts
or mozilla-rootcerts-openssl, and you update to a version of NetBSD
with certctl(8). In this case, certctl(8) should avoid destroying
your work.
While here, also test some related but less likely edge cases:
- nonexistent
- symlink
- regular file
references internal symbols in libcrypto like ossl_dh_compute_key which
have been made static by the linker script (they are still visible in the
archive version).
It does not longer output redundant `` (ipip-proto-4)'':
cba9b77a98
Now, these tests become passing again.
Thanks mlelstv@ for finding out upstream commit.
OK ozaki-r@
Somehow, despite manually verifying a build/install/test of every
revision in my patch series, I managed to commit the wrong version of
the file for what became rev. 1.9, so the test was just broken when
it went in and remained broken in the commit where I fixed the real
bug and removed the xfail marker on the test.
PR kern/5757
XXX pullup-10
XXX pullup-9
XXX pullup-8
As soon as the workqueue function has called, it is forbidden to
touch the struct work passed to it -- the function might free or
reuse the data structure it is embedded in.
So workqueue_wait is forbidden to search the queue for the batch of
running work items. Instead, use a generation number which is odd
while the thread is processing a batch of work and even when not.
There's still a small optimization available with the struct work
pointer to wait for: if we find the work item in one of the per-CPU
_pending_ queues, then after we wait for a batch of work to complete
on that CPU, we don't need to wait for work on any other CPUs.
PR kern/57574
XXX pullup-10
XXX pullup-9
XXX pullup-8
Since tree.c 1.552 from 2023-07-08, lint warned about integer
conversions from 'int' or 'unsigned int' to smaller integer types. This
only affected 32-bit platforms where size_t is 'unsigned int' rather
than 'unsigned long', as on these platforms, the integer ranks of 'int'
and 'long' are the same, see INT_RANK in inittyp.c.
Discovered by lib/libkvm, which fails on i386 when lint generates any
warnings.
this introduces 4 new warning disable flags:
CC_WNO_MISSING_TEMPLATE_KEYWORD
CC_WNO_REGISTER
CC_WNO_STRINGOP_OVERREAD
CC_WNO_ARRAY_BOUNDS
and documents them in README.warnings. of these, the string op
and array bounds are both problematic (real bugs) and also spurious
(not real bugs), and the other 2 are mostly temporary for older
3rd party code.
add some new uses of CC_WNO_STRINGOP_OVERFLOW.
fix m68k build for gallium and GCC 12.
Can probably make this work through rumphijack, but there's no sense
in even trying the test if we can't, so let's reduce the unprivileged
false alarms.
rillig