| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
| |
while there's no POSIX namespace provision for UIO_* in uio.h, this
exact macro name is reserved in XBD 2.2.2. apparently some
glibc-centric software expects it to exist, so let's provide it.
|
| |
|
|
|
|
| |
POSIX is not clear on whether it includes the termination, but ISO C
requires that it does. the whole concept of this macro is rather
useless, but it's better to be correct anyway.
|
| |
|
|
|
|
|
| |
the main use for this macro seems to be knowing the correct allocation
granularity for dynamic-sized fd_set objects. such usage is
non-conforming and results in undefined behavior, but it is widespread
in applications.
|
| | |
|
| | |
|
| |
|
|
|
|
| |
a research in debian codesearch and grepping over the pkgsrc
directory tree have shown that these macros are all either unused,
or defined by programs in case they need them.
|
| |
|
|
|
|
| |
these would not be expensive to actually implement, but reading
/etc/ethers does not sound like a particularly useful feature, so for
now I'm leaving them as stubs.
|
| |
|
|
|
|
|
|
| |
in theory this should not be an issue, since major() should only be
applied to type dev_t, which is 64-bit. however, it appears some
applications are not using dev_t but a smaller integer type (which
works on Linux because the kernel's dev_t is really only 32-bit). to
avoid the undefined behavior, do it as two shifts.
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
| |
this type is not really intended to be used; it's just there to allow
implementations to choose the type for the shm_nattch member of
struct shmid_sh, presumably since historical implementations disagreed
on the type. in any case, it needs to be there, so now it is.
|
| |
|
|
|
|
|
| |
the pathnames prefixed with /dev/null/ are guaranteed never to be
valid. the previous use of /dev/null alone was mildly dangerous in
that bad software might attempt to unlink the name when it found a
non-regular file there and create a new file.
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
despite declaring functions that take arguments of type va_list, these
headers are not permitted by the c standard to expose the definition
of va_list, so an alias for the type must be used. the name
__isoc_va_list was chosen to convey that the purpose of this alternate
name is for iso c conformance, and to avoid the multitude of names
which gcc mangles with its hideous "fixincludes" monstrosity, leading
to serious header breakage if these "fixes" are run.
|
| |
|
|
|
|
|
|
|
| |
also move all legacy inet_* functions into a single file to avoid
wasting object file and compile time overhead on them.
the added functions are legacy interfaces for working with classful
ipv4 network addresses. they have no modern usefulness whatsoever, but
some programs unconditionally use them anyway, and they're tiny.
|
| |
|
|
|
|
|
| |
based on patch by Strake with minor stylistic changes, and combined
into a single file. this patch remained open for a long time due to
some question as to whether ether_aton would be better implemented in
terms of sscanf, and it's time something was committed, so here it is.
|
| |
|
|
|
|
|
|
|
|
| |
arguably CLOCK_MONOTONIC should be redirected to CLOCK_BOOTTIME with a
fallback for old kernels that don't support it, since Linux's
CLOCK_BOOTTIME semantics seem to match the spirit of the POSIX
requirements for CLOCK_MONOTONIC better than Linux's version of
CLOCK_MONOTONIC does. however, this is a change that would require
further discussion and research, so for now, I'm simply making them
all available.
|
| |
|
|
|
|
| |
originally it was right on 32-bit archs and wrong on 64-bit, but after
recent changes it was wrong everywhere. with this commit, it's now
right everywhere.
|
| |
|
|
|
| |
defining tm_gmtoff and tm_zone as macros was breaking some application
code that used these names for its own purposes.
|
| | |
|
| |
|
|
|
|
|
|
| |
there was some question as to how many decimal places to use, since
one decimal place is always sufficient to identify the smallest
denormal uniquely. for now, I'm following the example in the C
standard which is consistent with the other min/max macros we already
had in place.
|
| |
|
|
|
|
|
| |
somehow I missed this when removing the corresponding
__STDC_LIMIT_MACROS and __STDC_CONSTANT_MACROS nonsense from stdint.h.
these were all attempts by the C committee to guess what the C++
committee would want, and the guesses turned out to be wrong.
|
| | |
|
| |
|
|
|
|
| |
__FLOAT_BITS and __DOUBLE_BITS macros used union compound literals,
now they are changed into static inline functions. A good C compiler
generates the same code for both and the later is C++ conformant.
|
| |
|
|
|
|
|
| |
C++11, the first C++ with stdint.h, requires the previously protected
macros to be exposed unconditionally by stdint.h. apparently these
checks were an early attempt by the C committee to guess what the C++
committee would want, and they guessed wrong.
|
| |
|
|
|
|
| |
the getifaddrs interface seems to have been invented by glibc, and
they expose socket.h, so for us not to do so is just gratuitous
incompatibility with the interface we're mimicing.
|
| |
|
|
|
|
|
|
|
|
| |
this is a bit ugly, and the motivation for supporting it is
questionable. however the main factors were:
1. it will be useful to have this for certain internal purposes
anyway -- things like syslog.
2. applications can just save argv[0] in main, but it's hard to fix
non-portable library code that's depending on being able to get the
invocation name without the main application's help.
|
| | |
|
| |
|
|
|
|
| |
supports ipv4 and ipv6, but not the "extended" usage where
usage statistics and other info are assigned to ifa_data members
of duplicate entries with AF_PACKET family.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
the preprocessor can reliably determine the signedness of wchar_t.
L'\0' is used for 0 in the expressions so that, if the underlying type
of wchar_t is long rather than int, the promoted type of the
expression will match the type of wchar_t.
|
| | |
|
| |
|
|
|
|
|
|
|
| |
since shadow does not yet support enumeration (getspent), the
corresponding FILE-based get and put versions are also subbed out for
now. this is partly out of laziness and partly because it's not clear
how they should work in the presence of TCB shadow files. the stubs
should make it possible to compile some software that expects them to
exist, but such software still may not work properly.
|
| |
|
|
|
|
|
|
| |
this type was removed back in 5243e5f1606a9c6fcf01414e ,
because it was removed from the XSI specs.
however some apps use it.
since it's in the POSIX reserved namespace, we can expose it
unconditionally.
|
| |
|
|
| |
the contents of this header are already in arpa/nameser.h
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
this fix is far from ideal and breaks the rule of not using
arch-specific #ifdefs, but for now we just need a solution to the
existing breakage.
the underlying problem is that the kernel folks made a very stupid
decision to make misalignment of this struct part of the kernel
API/ABI for x86_64, in order to avoid writing a few extra lines of
code to handle both 32- and 64-bit userspace on 64-bit kernels. I had
just added the packed attribute unconditionally thinking it was
harmless on 32-bit archs, but non-x86 32-bit archs have 8-byte
alignment on 64-bit types.
|
| | |
|
| | |
|
| |
|
|
| |
patch by Chris Spiegel.
|
| | |
|
| |
|
|
|
| |
this macro is 100 on all archs, at least in userspace, according
to kernel headers.
|
