based on patches by orc and Isaac Dunham, with some fixes. sys/io.h
exists and contains prototypes for these functions regardless of
whether the target arch has them; this is a bit unorthodox but I don't
think it will break anything. the function definitions do not exist
unless the appropriate SYS_* syscall number macro is defined, which
should make sure configure scripts looking for these functions don't
find them on other systems.
presently, sys/io.h does not have the inb/outb/etc. port io
macros/functions. I'd be surprised if ioperm/iopl are useful without
them, so they probably need to be added at some point in appropriate
bits/io.h files...
the kernel wrongly expects the cmsg length field to be size_t instead
of socklen_t. in order to work around the issue, we have to impose a
length limit and copy to a local buffer. the length limit should be
more than sufficient for any real-world use; these headers are only
used for passing file descriptors and permissions between processes
over unix sockets.
this is ugly and stupid, but now that the *64 symbol names exist, a
lot of broken GNU software detects them in configure, then either
breaks during build due to missing off64_t definition, or attempts to
compile without function declarations/prototypes. "fixing" it here is
easier than telling everyone to add yet another feature test macro to
their builds.
there is no reason to avoid multiple identical macro definitions; this
is perfectly legal C, and even with the maximal warning options
enabled, gcc does not issue any warning for it.
- add the rest of the junk traditionally in sys/param.h
- add prototypes for some nonstandard functions
- add _GNU_SOURCE to their source files so the compiler can check proto
the changes to syscall_ret are mostly no-ops in the generated code,
just cleanup of type issues and removal of some implementation-defined
behavior. the one exception is the change in the comparison value,
which is fixed so that 0xf...f000 (which in principle could be a valid
return value for mmap, although probably never in reality) is not
treated as an error return.
casting to int would not be correct because high bits could be lost.
mapping the high bits down onto low bits would be costlier in the
common case where the result is just used in a conditional. changing
the type of the bit array elements to int would permute the order of
the bit array on 64-bit big endian systems, so that's not an option
either.
this is a case of poorly written man pages not matching the actual
implementation, and why i hate implementing nonstandard interfaces
with no actual documentation of how they're intended to work.
some of these definitions were just plain wrong, others based on
outdated ancient "non-64" versions of the kernel interface.
as much as possible has now been moved out of bits/*
these changes break abi (the old abi for these functions was wrong),
but since they were not working anyway it can hardly matter.
Rich Felker