it's UB to fetch variadic args when none are passed, and this caused
real crashes on ppc due to its calling convention, which defines that
for variadic functions aggregate types be passed as pointers.
the assignment caused that pointer to get dereferenced, resulting in
a crash.

per POSIX, the variadic argument has type union semun, which may
contain a pointer or int; the type read depends on the command being
issued. this allows the userspace part of the implementation to be
type-correct without requiring special-casing for different commands.
the kernel always expects to receive the argument interpreted as
unsigned long (or equivalently, a pointer), and does its own handling
of extracting the int portion from the representation, as needed.

this change fixes two possible issues: most immediately, reading the
argument as a (signed) long and passing it to the syscall would
perform incorrect sign-extension of pointers on the upcoming x32
target. the other possible issue is that some archs may use different
(user-space) argument-passing convention for unions, preventing va_arg
from correctly obtaining the argument when the type long (or even
unsigned long or void *) is passed to it.

this should not matter since the reality is that either all the sysv
sem syscalls are individual syscalls, or all of them are multiplexed
on the SYS_ipc syscall (depending on arch). but best to be consistent
anyway.

this is a Linux-specific extension to the sysv semaphore api.

rather than returning an error, we have to increase the size argument
so high that the kernel will have no choice but to fail. this is
because POSIX only permits the EINVAL error for size errors when a new
shared memory segment would be created; if it already exists, the size
argument must be ignored. unfortunately Linux is non-conforming in
this regard, but I want to keep the code correct in userspace anyway
so that if/when Linux is fixed, the behavior applications see will be
conforming.

rejecting invalid values for n is fine even in the case where a new
sem will not be created, since the kernel does its range checks on n
even in this case as well.

by default, the kernel will bound the limit well below USHRT_MAX
anyway, but it's presumably possible that an administrator could
override this limit and break things.

also cleanup cruft related to the issue