with an IQ that underflows when one attempts to enter it as an
unnormalised 160 bit long long double...
Whoever would believe that (~0 & anything) was a meaningful thing
to write? And three times in one #define. That could not possibly
have been me, could it?
Simplify, simplify, simplify. NFC.
to allow bash to build fdflags on Solaris 10, here are some mods that
fix that, and some other similar issues in the NetBSD version of fdflags.
The bash implementation of fdflags is based upon the one Christos did for
the NetBSD sh, so the issues are similar ... the NetBSD sh cannot yet
(easily anyway) build on anything except NetBSD, so this change makes
no current difference at all (just adds some compile time tests (#ifdef)
which always work out the way things did before, when built on NetBSD).
However, there is no system on which any modern shell can hope to work
which does not support close on exec, or fcntl(F_SETFD,...) to set it.
The O_CLOEXEC and FD_CLOEXEC definitions might not exist, but close on
exec can still be manipulated. Since the primary rationale for
the fdflags builtin was to be able to manipulate that state bit from
scripts, it would be annoying to lose that one, and keep all the (less
important) others, just because O_CLOEXEC is not defined, so do the
fix (workaround) a different way than was done in the bash patch.
Further, more than fdflags() will fail if O_CLOEXEC is not defined,
so handle that as well.
Also fix another oddity ... (noticed by reading the code) - if
fcntl(F_GETFL,...) returned any bits set that we don't understand,
the code was supposed to simply print their values as a hex constant,
when fdflags is run with -v. However, the getflags() function was
clearing all bits that the code did not know about ... so there is
no way any unknown bit could ever make it out to be printed. Handle
that a different way - instead of clearing unknown bits, clear any
bits that get returned which we understand, but do not want to deal
with (stuff like O_WRONLY, which should not be returned from the
fcntl(), but who knows...) Leave any unknown bits that happen to be
set, set, so that printone() can display them if appropriate.
(This is most likely to happen when running an older shell on a new
kernel where the kernel supports some new flag that the shell has
not been taught to understand).
NFCI that anyone should notice anytime soon.
(how many more builds will i find like this? the end result
is that i think we should generate the ./usr/include/$MACHINE
entry, i think, but i have to survey many ports.)
per-user basis not a per-process. We cannot really keep track on
a per-process basis because a parent process can create the semaphore
and a child can free it taking credit for it. There is also a
similar issue about resource exhaustion if we limited the number
of lwps per process as opposed to per user (which we don't).
the real cause of yet.
mark npf_init() as non-static. for a yet-unknown reason, when this
function is inlined by the compiler (or a human!) into the single
caller, some CPUs end up in a hung state that can't be interrupted
eventually leading to system hang. eg:
[ 8.9693040] root on hme0
[ 8.9862690] nfs_boot: trying DHCP/BOOTP
xcall(cpu2,0xf0240ac8) from 0xf0241170: couldn't ping cpus: cpu1
is the symptom though sometimes nfs_boot is actually able to
complete mountroot before it hangs.
this may be a compiler bug but the symptom and the trigger are
far removed and my so-far reading of the "broken" npf_init
inlining has shown no issues, however, i haven't completed a
full scan of this asm in the past month so i'm commiting this
workaround for now.
account the trailing NUL on each name. Some other similar instances of
this idiom already account for this.
(In preparation to factor out this idiom into its own function.)
matches the internal CTL* chars.
The earlier fixes handled CTL* char values in var expansions,
but not in various other places they can occur (positional
parameters, $@ $* -- even potentially $0 and ~ expansions,
as well as byte strings generated from a \u in a $'' string).
These should all be correctly handled now. There is a new
ISCTL() macro to make the test, rather than using the old
BASESYNTAX[c]==CCTL form (which us still a viable alternative)
as the new way allows compiler optimisations, and less mem
references, so it should be smaller and faster.
Also, be sure in all cases to remove any CTLESC (or other)
CTL* chars from all strings before they are made available
for any external use (there was one case missed - which didn't
matter when we weren't bothering to escape the CTL* chars at
all.)
XXX pullup-8 (will need to be via a patch) along with the Feb 4 fixes.
In the function the routing table could be accessed without any locks, which was
unsafe. Actually, on netbsd-7, a kernel panic happened(*). The situation of
locking hasn't changed since netbsd-7 so we still need to hold the big locks on
-current (and netbsd-8) too.
Note that if NET_MPSAFE is enabled, the routing table is protected by its own
lock and we don't need the locks.
Reported and tested on netbsd-7 by sborrill@
(*) http://mail-index.netbsd.org/tech-net/2018/11/08/msg007153.html
