will overlap with the requested scheduler range, so get the new scheduler
range, and then try to find a different priority. If that fails (to find
a different scheduling range), give up here.
to my message on tech-userlevel ...
Subject: tests/lib/libpthread/t_mutex:mutex6
Date: Thu, 23 Nov 2017 17:34:54 +0700
Message-ID: <28385.1511433294@andromeda.noi.kre.to>
which can be found at:
http://mail-index.netbsd.org/tech-userlevel/2017/11/23/msg011010.html
which analysed the mutex6 test case of this test, and concluded
that it was useless, nonsense, and broken (the whole test is just a
race - not even really using or testing mutexes), let it be henceforth
forever gone.
more precision bits than the data type expects, but (kind of obviously)
does not allow such values to be stored in memory, expecting the value
returned from strtod() (an intermediate result) to be identical (that is,
equal) to a stored value is incorrect.
So instead go back to checking that the two numbers are very very close.
See comments added to the test for more explanation.
computed using different methods, don't expect to achieve identical
results (here, one constant is perhaps converted to binary from a string by
a cross compiler, the other is converted at run time). Allow them to
have a small difference (for now, small is < 1e-7 - the constant is ~ 1e5,
so this is 12 orders of magnitude less) before failing (and include the
actual difference in the error message if it does fail.)
Move libevent from being a test playing sub-directory, to a groupy,
just hanging around, hoping someone will notice it, and throw it
a bone... (mixed metaphors?)
failure occurs, distinguish in the failure message the cases where the
open succeeded (and should not have), and where it failed, but not for
the expected reason (the "wrong errno" case not tested, would require
manufacturing a broken kernel...).
Add O_NOFOLLOW ('l' mode modifier) tests to the fopen_mode test case
(tests that are intended to open the file) and also add a few missing
commas which were causing a few of the sub-tests to be skipped, and
others to be not quite testing exactly what was intended.
to leave errno unaltered if there is no error. And does not.
While here, write -1 the same way everyone else does (not ~0, which
would not even be negative on a 1's complement host, if you can find one).
And while not needed for the test, but so that if checked, the result is
more likely to be what is anticipated, set tm_mday to an in-range value
in the mtime_negyear test (otherwise the correction results in the result
movng backwards to the last day of the previous month, which is the
end of Decemper, 1898, rather than the 1899 one would expect from year -1.)
to its previous state, so any signals that occur during the rest of the
test gat handled just as they would (core dump) as if the handler was never
executed. No need to bother if the SYSVMSG test fails, as in that case,
nothing else will be done anyway.
PROT_MPROTECT(), or if the test is built without _NETBSD_SOURCE defined,
by providing a dummy #define if the real one does not exist. The test
might then fail, if the PROT_MPROTECT() is really needed, but that's
better than not building.
PROT_MAXPROTECT or PROT_ALLOWPROTECT or something) on the mmap() call
which specifies PROT_NONE, and which we later want to change to PROT_READ,
otherwise when PAX is enabled, the mprotect() will fail.
2822 specifications. Unfortunately they are specified incorrectly in
RFC-822 and not very clearly in RFC 2822. RFC 1123 clearly states they
are specified incorrectly - counting the wrong way from UTC - in RFC
822. RFC 2822 just states they were implemented in a non-standard way.
Mea culpa for not noticing when originally implemented. Fix them so
the correct calculations are made.
martin