tl;dr process-running? would always return #f on OpenBSD and
NetBSD, and in the one-argument case it would always return #t
on DragonFly.
To get the process information from the process table on OpenBSD
and NetBSD, we need to pass 6 level names to sysctl instead of 4.
Passing the wrong number of level names to sysctl has caused it
to always fail, which in turn caused process-running? to always
return #f:
(process-running? 1) => #f
(process-running? (current-process-id)) => #f
and so on.
After the above fix, we also need to check the amount of data
actually filled in by sysctl. It appears that on OpenBSD, NetBSD
and DragonFly, if the requested process doesn't exist then sysctl
will return with a return value of 0 and just not actually fill in
the given structure. This caused process-running? to return #t
when no process with the given PID existed:
(process-running? -1) => #t
(process-running? <other nonexistent pid>) => #t
and so on.
I have tested on OpenBSD, NetBSD, DragonFly BSD and FreeBSD, and
process-running? now behaves as expected on all of them.
* Include util.h instead of pty.h on OpenBSD and NetBSD
* Include libutil.h instead of pty.h on FreeBSD and DragonFly BSD
* Include utmp.h only on non-BSD systems (FreeBSD does not have that
header and none of these BSDs require it)
Tested on all four of these BSDs.
On NetBSD systems the netbsd feature identifier was not actually
provided because the macro SEXP_NETBSD was defined twice and the
second value was 0.
On DragonFly systems the dragonfly feature identifier was not actually
provided because the macro SEXP_DRAGONFLY was defined twice and the
second value was 0. Also on DragonFly systems the darwin feature
identifier was incorrectly provided because SEXP_DARWIN had a value of
1 instead of 0.
When char-set, w/case, w/nocase, w/ascii or w/unicode is applied on a
<cset-sre>, only (cadr sre) is taken, the rest is ignored. Which is the
right thing to do only if (null? (cddr sre)). If there are more
arguments, error out instead of silently ignoring them.
Introduce SEXP_STATIC_LIBRARY to support static-library build on
Win32/Win64. On Win32, symbol visibility is enforced on DLL builds so we
need to dedicated ABI on static-library builds.
Under Unix with SEXP_64_BIT defined, sexp_sint_t is defined as 'long'.
But we would get the equivalent format specifier SEXP_PRIdFIXNUM from
the OS-defined PRId64 in <inttypes.h>. MacOS defines it as "lld". This
causes the clang printf checker to emit a warning about the 'long' and
'long long' mismatch.
Fix by avoiding system-defined PRId32 and PRId64 format specifiers and
always defining SEXP_PRIdFIXNUM as "d", "ld" or "lld" according to our
definition of sexp_sint_t as int, long or long long. This also means
we don't need to include <inttypes.h> any more.
