| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
| |
most of the members should be time_t anyway, and time_t has the
correct semantics for "syscall_long", so it works on all archs, even x32.
|
|
|
|
|
| |
this was a missing part of the LFS64 API; it's "needed" for use with
fcntl and the corresponding lock commands.
|
|
|
|
|
| |
another commit to silence gcc warnings (-Wparentheses) for standard headers.
changed macros: LOG_UPTO, IN6_ARE_ADDR_EQUAL
|
|
|
|
|
|
| |
gcc -Wsign-compare warns about expanded macros that were defined in
standard headers (before gcc 4.8) which can make builds fail that
use -Werror. changed macros: WIFSIGNALED, __CPU_op_S
|
|
|
|
|
|
|
|
|
|
|
| |
the affected part of the header is responsible for providing both GNU
and BSD versions of the udphdr structure. previously, the
namespace-polluting GNU names were always used for the actual struct
members, and the BSD names, which are named in a manner resembling a
sane namespace, were always macros defined to expand to the GNU names.
now, unless _GNU_SOURCE is defined, the BSD names are used as the
actual structure members, and the macros and GNU names only come into
play when the application requests them.
|
|
|
|
|
|
| |
policy is to avoid using these types except where they are needed for
namespace conformance. C99-style stdint.h types should be used
instead.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
there are two versions of this structure: the BSD version and the GNU
version. previously only the GNU version was supported. the only way
to support both simultaneously is with an anonymous union, which was a
nonstandard extension prior to C11, so some effort is made to avoid
breakage with compilers which do not support anonymous unions.
this commit is based on a patch by Timo Teräs, but with some changes.
in particular, the GNU version of the structure is not exposed unless
_GNU_SOURCE is defined; this both avoids namespace pollution and
dependency on anonymous unions in the default feature profile.
|
|
|
|
|
|
|
|
| |
these are poorly designed (illogical argument order) and even poorly
implemented (brace issues) on glibc, but unfortunately some software
is using them. we could consider removing them again in the future at
some point if they're documented as deprecated, but for now the
simplest thing to do is just to provide them under _GNU_SOURCE.
|
|
|
|
|
|
|
|
| |
some applications expect it to be defined, despite the standard making
it impossible for it to ever be returned as a value distinct from
NO_DATA. since these macros are outside the scope of the current
standards, no special effort is made to hide NO_ADDRESS under
conditions where the others are exposed.
|
|
|
|
|
|
|
|
| |
in fixing this, I've changed the logic from ugly #if/#else blocks
inside the struct shm_info definition to a fixed struct definition and
optional macros to rename the elements. this will be helpful if we
need to move shm_info to a bits header in the future, as it will keep
the feature test logic out of bits.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
the imr_, imsf_, ip6_, ip6m_, ipi_, ipi6_, SCM_, and SOL_ prefixes are
not in the reserved namespace for this header. thus the constants and
structures using them need to be protected under appropriate feature
test macros.
this also affects some headers which are permitted to include
netinet/in.h, particularly netdb.h and arpa/inet.h.
the SOL_ macros are moved to sys/socket.h where they are in the
reserved namespace (SO*). they are still accessible via netinet/in.h
since it includes sys/socket.h implicitly (which is permitted).
the SCM_SRCRT macro is simply removed, since the definition used for
it, IPV6_RXSRCRT is not defined anywhere. it could be re-added, this
time in sys/socket.h, if the appropriate value can be determined;
however, given that the erroneous definition was not caught, it is
unlikely that any software actually attempts to use SCM_SRCRT.
|
|
|
|
|
|
|
| |
it's unclear what the historical signature for this function was, but
semantically, the argument should be a pointer to const, and this is
what glibc uses. correct programs should not be using this function
anyway, so it's unlikely to matter.
|
|
|
|
|
| |
both the kernel and glibc agree that this argument is unsigned; the
incorrect type ssize_t came from erroneous man pages.
|
|
|
|
|
|
| |
this change is consistent with the corresponding glibc functions and
is semantically const-correct. the incorrect argument types without
const seem to have been taken from erroneous man pages.
|
|
|
|
|
|
|
| |
this functionality has essentially always been deprecated in linux,
and was never supported by musl. the presence of the header was
reported to cause some software to attempt to use the nonexistant
function, so removing the header is the cleanest solution.
|
|
|
|
|
|
| |
this was wrong since the original commit adding inotify, and I don't
see any explanation for it. not even the man pages have it wrong. it
was most likely a copy-and-paste error.
|
|
|
|
|
|
| |
the type int was taken from seemingly erroneous man pages. glibc uses
in_addr_t (uint32_t), and semantically, the arguments should be
unsigned.
|
|
|
|
|
|
|
| |
this agrees with implementation practice on glibc and BSD systems, and
is the const-correct way to do things; it eliminates warnings from
passing pointers to const. the prototype without const came from
seemingly erroneous man pages.
|
| |
|
| |
|
|
|
|
|
|
|
| |
ssi_ptr is really 64-bit in kernel, so fix that. assuming sizeof(void*)
for it also caused incorrect padding for 32-bits, as the following
64-bits are aligned to 64-bits (and the padding was not taken into
account), so fix the padding as well. add addr_lsb field while there.
|
|
|
|
| |
based on patch by Timo Teräs; greatly simplified to use fprintf.
|
|
|
|
| |
based on patch by Timo Teräs.
|
|
|
|
| |
based on patch by Timo Teräs.
|
| |
|
|
|
|
|
| |
this is purely a wrapper for close since Linux does not support EINTR
semantics for the close syscall.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
historically these functions appeared in BSD 4.3 without prototypes,
then in the bind project prototypes were added to resolv.h, but those
were incompatible with the definitions of the implementation.
the bind resolv.h became the defacto api most systems use now, but the
old internal definitions found their way into the linux manuals and thus
into musl.
|
| |
|
| |
|
|
|
|
|
| |
at least a couple of these are used on BSD too, and the FNM_*
namespace is reserved in fnmatch.h anyway.
|
|
|
|
|
|
|
|
| |
the old value of 20 was reported by Laurent Bercot as being
insufficient for a reasonable real-world usage case. actual problem
was the internal buffer used by ttyname(), but the implementation of
ttyname uses TTY_NAME_MAX, and for consistency it's best to increase
both. the new value is aligned with glibc.
|
|
|
|
|
|
|
|
|
|
| |
on archs with excess precision, the floating point constant 1e40f may
be evaluated such that it does not actually produce an infinity.
1e5000f is sufficiently large to produce an infinity for all supported
floating point formats. note that this definition of INFINITY is only
used for old or non-GNUC compilers anyway; despite being a portable,
conforming definition, it leads to erroneous warnings on many
compilers and thus using the builtin is preferred.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
unfortunately this eliminates the ability of the compiler to diagnose
some dangerous/incorrect usage, but POSIX requires (as an extension to
the C language, i.e. CX shaded) that NULL have type void *. plain C
allows it to be defined as any null pointer constant.
the definition 0L is preserved for C++ rather than reverting to plain
0 to avoid dangerous behavior in non-conforming programs which use
NULL as a variadic sentinel. (it's impossible to use (void *)0 for C++
since C++ lacks the proper implicit pointer conversions, and other
popular alternatives like the GCC __null extension seem non-conforming
to the standard's requirements.)
|
|
|
|
| |
This function is used by ping6 from iputils.
|
|
|
|
| |
some macros in sys/mtio.h and syslog.h used NULL without defining it
|
| |
|
| |
|
|
|
|
|
| |
and use _GNU_SOURCE || _BSD_SOURCE guards for all of the RFC 3678
namespace polluting things like glibc/uclibc does.
|
|
|
|
|
|
|
| |
previously:
timersub(&now, t, &diff);
warning: value computed is not used [-Wunused-value]
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
this is enough to produce the correct value even if the constant is
interpreted as 80-bit extended precision, which matters on archs with
excess precision (FLT_EVAL_METHOD==2) under at least some
interpretations of the C standard. the shorter representations, while
correct if converted to the nominal precision at translation time,
could produce an incorrect value at extended precision, yielding
results such as (double)DBL_MAX != DBL_MAX.
|
|
|
|
|
|
|
|
|
|
|
|
| |
siginfo_t is not available from signal.h when the strict ISO C feature
profile (e.g. passing -std=c99 to gcc without defining any other
feature test macros) is used, but the type is needed to declare
waitid. using sys/wait.h (or any POSIX headers) in strict ISO C mode
is an application bug, but in the interest of compatibility, it's best
to avoid producing gratuitous errors. the simplest fix I could find is
suppressing the declaration of waitid (and also signal.h inclusion,
since it's not needed for anything else) in this case, while still
exposing everything else in sys/wait.h
|
|
|
|
|
|
| |
while using "l" unconditionally gave the right behavior due to
matching sizes/representations, it was technically UB and produced
compiler warnings with format string checking.
|
| |
|
|
|
|
|
|
| |
despite being marked legacy, this was specified by SUSv3 as part of
the XSI option; only the most recent version of the standard dropped
it. reportedly there's actual code using it.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
fcntl.h: AT_* is not a reserved namespace so extensions cannot be
exposed by default.
langinfo.h: YESSTR and NOSTR were removed from the standard.
limits.h: NL_NMAX was removed from the standard.
signal.h: the conditional for NSIG was wrongly checking _XOPEN_SOURCE
rather than _BSD_SOURCE. this was purely a mistake; it doesn't even
match the commit message from the commit that added it.
|