Previously, lint accepted -X '1, 2, 3', while the manual page lists the
IDs without spaces.
On 32-bit platforms, lint accepted -X -4294967295, and on 64-bit
platforms, it accepted the corresponding larger numbers.
The code for parsing message IDs and query IDs conceptually does the
same, but the implementations differed for no reason.
New test case that reflects the fix in PR kern/57260. The majority of
work for this case itself was by riastradh@, who'd supplied the basis
for it in the ticket, and provided further guidance.
https://mail-index.netbsd.org/tech-userlevel/2023/03/15/msg013727.html
The previous attempt (message 351 about 'extern' declarations outside
headers) did not cover the proposal from the tech-userlevel mailing list
but instead warns about a different usage pattern of the 'extern'
keyword.
to the next instruction. Only ERESTART should return to
the same instruction. Differences to sparc64 reduced.
Test t_ptrace_wait:syscallemu1 now passes on sparc.
Fixes PR kern/52166 "syscallemu does not work on sparc (32-bit)"
Ok: Martin Husemann
to what the shell produces for tilde expansions, when the expansion
of the tilde prefix ends with '/' and the character immediately following
is another '/' - previously /bin/sh (and most other shells, but not all)
retained both slashes, and this test expected that behaviour.
No longer, now only one of the two will appear. Adjust the expected
test results accordingly, and add an extra loop iteration to make sure
this is thoroughly tested (one more tilde expansion value).
Also, add two new test cases that test for the new (explicit - though
it was always stated this way, but not as explicitly) that if HOME is
an empty string (not unset - that remains an unspecified case, as it
was) then the expansion of ~ must generate "", and not nothing.
The current test was unable to distinguish those two, since it
simply looked for characters in the output, so add a new test cases
explicitly to test for this particular case. This also means (also
previously in the standard, but not as explicitly) that shells are
not permitted to decide "The ~ expansion produces an empty string, that
is weird, let's generate something else instead" which some shells were
doing.
For large integer constants, the resulting type could differ between
traditional C and C90. In C99 mode, this difference is no longer
relevant since it is too far away from traditional C.
The names of the tests were misleading: 'recursive' should have been
'nested', and the interesting topic in the 'cast' tests was not the cast
but the pointer dereference.
Following the C11 grammar, the keyword '_Atomic' needs to be a separate
syntactic category, to avoid further conflicts in the grammar.
The two newly added conflicts in the grammar would come into play when
mixing traditional C with C11, in a type name without an implicit 'int'.
If the type '_Atomic(int)*' were parsed as '_Atomic int(int)*', the
trailing '*' would be a syntax error.
And make the tests work, and exercise all lengths up to 100.
Evidently the previous definition, presumably tightly optimized for
1980s-era compilers and CPUs, was too hard to understand, because it
was incorrectly tested for two decades and broken for years.
PR lib/57141
XXX pullup-8
XXX pullup-9
XXX pullup-10
process scheduling works. That a process (or in this case,
a thread) is no longer blocked at time T does not mean that it
will resume execution at time T. The OS is free to devote
resources to other processes/threads instead - all we should
normally be able to expect is that if it is not unblocked before
time T, that it will not start running before then.
In general though, the pthread_cond_*wait() functions don't guarantee
even that - but for this test, the possibility of something else
randomly signalling the condvar isn't believable, so don't worry about
that possibility (but do fail without calling strerror(0) on the off
chance it does happen).
Once we cease testing that the process resumed running before some
particular time, we can stop dealing with qemu timekeeping issues,
it might (seem to) take qemu twice as long as was requested before
the thread resumes, but that's OK - the same thing could happen on
a loaded system for other reasons.
Beyond that, the test also has (had) a race condition. When using
CLOCK_REALTIME though that clock needed to have advanced to T before
the ETIMEDOUT should happen, there is no guarantee that it will stay >T
(CLOCK_REALTIME is allowed to be reset backwards). So, only test
that the current time (after ETIMEDOUT) >= T when we're using
CLOCK_MONOTONIC - for CLOCK_REALTIME the time might have stepped
back between when the ETIMEDOUT happened and when the thread
obtains the current clock reading. For that case, all we can test
is that the ETIMEDOUT actually happens.
With much of what was there now gone, the code can be simplified,
we no longer need to do timespec arithmetic, just one comparison
(simpler to test that Tend >= Tstart+period than Tend-Tstart > period
as we need Tstart+period for the abstime value for the timeout anyway).
Note that this still tests for the issue reported in PR lib/47703
which is where the test came from in the first place.
ps: we seem to be missing pthread_cond_clockwait() which is the same
as pthread_cond_timedwait() except that the clock to use is passed
as a parameter, rather than as an attribute of the condition variable.
To test e.g., the file "/some/where/protocols" instead of "/etc/protocols",
set TEST_FILE=/some/where/protocols in your environment.
Note: this now compares the contents of the file you gave versus what
getprotoent(3)/getservent(3) uses (which still is /etc/protocols via
h_protoent.c / /etc/services or /var/db/services.cdb via h_servent.c).
When you have expected changes in the services or protocols file that
you're generating, this necessarily produces a difference. To really
allow testing the file versus what the library function returns, you'd
have to install the file on the system running the test, but at least
with this change you can now generate the file and verify that it didn't
caused unexpected differences.
for native /dev and create an alias for disk devices w/o partition
latter pointing at the raw partition, so for rump based tests we
actually have to calculate the concrete device name.
Use an idiom suggested by kre for this which also works for ports that
have kern.rawpartition > 4.
the secondary GPT header is moved. Do it this way rather than
just using -q to suppress the message, so the test verifies that
the appropriate action was taken.
As of:
commit 36c52a52eecf1ed0232f9e138564009a85de76c2
Author: Jonathan T. Looney <jtl@FreeBSD.org>
Date: Sat Nov 14 15:44:28 2020 +0000
Add a regression test for the port-selection behavior fixed in r367680.
disabling support in UFS2 for extended attributes (including ACLs).
Add a new variant of UFS2 called "UFS2ea" that does support extended attributes.
Add new fsck_ffs operations "-c ea" and "-c no-ea" to convert file systems
from UFS2 to UFS2ea and vice-versa (both of which delete all existing extended
attributes in the process).
correct so make the expected return ERR then repeat the call with
scrollok set to true to validate.
Do refreshes on the window instead of stdscr so we get the window
contents reported and update the check files with the expected
output.
error: queries.c(118): missing /* expect+1: implicit conversion
changes sign from 'char' to 'int' [Q3] */
error: queries.c(122): missing /* expect+1: implicit conversion
changes sign from 'char' to 'int' [Q3] */
uwe