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.
Use same calculation as getrusage, not some ad-hoc arithmetic of
internal scheduler parameters that are periodically rewound.
PR kern/57512
XXX pullup-8
XXX pullup-9
XXX pullup-10
Pointer casts from an integer type to a floating-point type and vice
versa get a 'maybe troublesome' warning now. The previous assumption
that all types of the same bit-size are convertible may have been valid
from a technical point of view, but still such code should get more
attention.
The rules for struct and union types could be made more fine-grained
later, if the need arises. To suppress this warning, it's always
possible to cast to an intermediate 'void *'.
Might help us to see if we're off by just a little bit (maybe a tiny
jitter between the hardclock timer and the monotonic clock), or if
something is seriously amiss when the timerfd_block test fails
sporadically.
This reverts the change from tree.c 1.547 from 2023-07-03. Back then, I
didn't know that the actual value from a type's 'portable size in bits'
was not supposed to be used.
The existing warning was only issued for function declarations, not for
function definitions.
The interesting change in the tests is in msg_351.c. Many other tests
use non-static functions due to their syntactic brevity. In these
tests, the warning is disabled individually, to allow new functions to
be added without generating warning 351.
Previously, in -w mode, any warning suppressed further 'unused'
warnings, even though there was no need to do that. This can be seen in
the test gcc_attribute_var.c, where only the last unused variable from a
function was marked as unused, the others slipped through.
Fixed by counting the errors and the warnings separately and only
combining them if actually desired.
1. Consolidate logic into a single helper.mk to reduce duplication.
2. Set NO* variables, not MK* variables which are reserved for user.
3. Avoid eager X!= in favour of lazy ${X:sh}.
4. Mark _g.a set list entries obsolete. Never should've been built!
PR misc/57462
- Test cartesian product of a sampling of sizes and a sampling of
alignments.
- Verify all the edge cases I could find in posix_memalign and
aligned_alloc, including failure modes.
- Test an unreasonably large (but aligned) allocation size.
- Use ATF_CHECK_* instead of ATF_REQUIRE_* so all failures will be
reported, not just the first one.
- While here, build with -fno-builtin-aligned_alloc and with
-fno-builtin-posix_memalign to make sure the compiler doesn't try
any shenanigans.
XXX pullup-10
Since tree.c 1.546 from 2023-07-03, lint no longer warned about possible
loss of accuracy when converting from 'long' to 'int' on an ILP32
platform that uses 'unsigned long' for size_t, when run in portable mode
(-p), which is enabled by default in the NetBSD build.
The integer constraints avoid false-positive warnings by looking at the
actual values an expression can take. The function can_represent is
guarded by a condition that uses the portable_size_in_bits, but then
internally used the opposite size_in_bits, which led to inconsistent
results.
The warning looks confusing though, as on an ILP32 platform, 'int' and
'long' have the same size and representation, therefore there cannot be
an actual loss of accuracy. The warning may need to be reworded to
explicitly mention the portability mode, in which sizeof(int) is assumed
to be 3 instead of 4, to catch possible loss of accuracy on other
platforms.
The previous prefix 'DK_' (declaration level kind) had a conflict with
the 'DK_' (designator kind) in init.c, so change the prefix to 'DLK_'.
The new name for dinfo_t is decl_level, which is more expressive.
No functional change.
The support for unnamed struct/union members that was added in decl.c
1.60 from 2015-10-13 was simple but wrong. It didn't cover initializers
of these structures and computed wrong sizes for structures containing
anonymous unions. At that time, the handling of initializers was broken
as well, it was fixed 6 years later in init.c 1.229 from 2021-12-22.
Real-life examples for code that lint couldn't handle are:
* external/bsd/jemalloc/dist/src/jemalloc.c
* external/mit/xorg/lib/dri.old/Makefile
When bit-fields in packed structs were added on 2009-10-02, lint assumed
that they would only use 'signed int' or 'unsigned int' as storage unit,
even though C99 also allows _Bool.
The cleanup commit for decl.c 1.225 from 2021-08-28 accidentally changed
the rounding mode for bit-field storage units from round-up to
round-down.
When running the tests via ATF, the filename was an absolute filename,
while the preprocessing line in the test file uses a relative filename.
These two didn't match.
Previously, 'indent run-equals-prev-output' was allowed even when there
was no 'indent run' section above. This created an ambiguity, since
'previous output' could mean either the 'indent run' section or the
'indent run-equals-input' section.
The assumption that in an expression of the form '(a * anything)', the
'*' marks a pointer type was too simple-minded.
For now, fix the obvious cases and leave the others for later. If
needed, they can be worked around using the '-T' option.
riastradh