| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
| |
traditionally, both BSD and GNU systems have it this way.
sys/syscall.h is purely syscall number macros. presently glibc exposes
the syscall declaration in unistd.h only with _GNU_SOURCE, but that
does not reflect historical practice.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
previously the names were exposed as key/seq with _GNU_SOURCE and
__ipc_perm_key/__ipc_perm/seq otherwise, whereas glibc always uses
__key and __seq for the names. thus, the old behavior never matched
glibc, and the new behavior always does, regardless of feature test
macros.
for now, i'm leaving the renaming here in sys/ipc.h where it's easy to
change globally for all archs, in case something turns out to be
wrong, but eventually the names could just be incorporated directly
into the bits headers for each arch and the renaming removed.
|
| |
|
| |
|
|
|
|
|
| |
the macro was the wrong way round, additionally GNU defines
__ prefixed versions, which are used by qemu.
|
|
|
|
|
|
| |
this function is obsolete, however it's available as a syscall
and as such qemu userspace emulation tries to forward it to the
host kernel.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
previously, a few BSD features were enabled only by _BSD_SOURCE, not
by _GNU_SOURCE. since _BSD_SOURCE is default in the absence of other
feature test macros, this made adding _GNU_SOURCE to a project not a
purely additive feature test macro; it actually caused some features
to be suppressed.
most of the changes made by this patch actually bring musl in closer
alignment with the glibc behavior for _GNU_SOURCE. the only exceptions
are the added visibility of functions like strlcpy which were BSD-only
due to being disliked/rejected by glibc maintainers. here, I feel the
consistency of having _GNU_SOURCE mean "everything", and especially
the property of it being purely additive, are more valuable than
hiding functions which glibc does not have.
|
| |
|
|
|
|
|
|
|
|
| |
these structures are purely for use by trace/debug tools and tools
working with core files. the definition of fpregset_t, which was
previously here, has been removed because it was wrong; fpregset_t
should be the type used in mcontext_t, not the type used in
ptrace/core stuff.
|
|
|
|
|
|
| |
apparently some other archs have sys/io.h and should not break just
because they don't have the x86 port io functions. provide a blank
bits/io.h everywhere for now.
|
|
|
|
|
|
|
| |
based on proposal by Isaac Dunham. nonexistance of bits/io.h will
cause inclusion of sys/io.h to produce an error on archs that are not
supposed to have it. this is probably the desired behavior, but the
error message may be a bit unusual.
|
|
|
|
|
| |
this is mostly junk, but a few programs with tape-drive support
unconditionally include it, and it might be useful.
|
|
|
|
|
|
| |
although a number is reserved for it, this option is not implemented
on Linux and does not work. defining it causes some applications to
use it, and subsequently break due to its failure.
|
| |
|
| |
|
|
|
|
|
|
| |
the W* namespace is not reserved, so the nonstandard ones must be
moved under extension features. also WNOHANG and WUNTRACED were
missing.
|
|
|
|
| |
it will be in the next version of POSIX
|
|
|
|
| |
issue reported/requested by Justin Cormack
|
|
|
|
| |
patch by Justin Cormack, with slight modification
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
now public syscall.h only exposes __NR_* and SYS_* constants and the
variadic syscall function. no macros or inline functions, no
__syscall_ret or other internal details, no 16-/32-bit legacy syscall
renaming, etc. this logic has all been moved to src/internal/syscall.h
with the arch-specific parts in arch/$(ARCH)/syscall_arch.h, and the
amount of arch-specific stuff has been reduced to a minimum.
changes still need to be reviewed/double-checked. minimal testing on
i386 and mips has already been performed.
|
|
|
|
| |
based on patch by Justin Cormack
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
the old behavior of exposing nothing except plain ISO C can be
obtained by defining __STRICT_ANSI__ or using a compiler option (such
as -std=c99) that predefines it. the new default featureset is POSIX
with XSI plus _BSD_SOURCE. any explicit feature test macros will
inhibit the default.
installation docs have also been updated to reflect this change.
|
|
|
|
|
|
|
|
| |
to deal with the fact that the public headers may be used with pre-c99
compilers, __restrict is used in place of restrict, and defined
appropriately for any supported compiler. we also avoid the form
[restrict] since older versions of gcc rejected it due to a bug in the
original c99 standard, and instead use the form *restrict.
|
|
|
|
|
|
|
|
|
| |
while musl itself requires a c99 compiler, some applications insist on
being compiled with c89 compilers, and use of "inline" in the headers
was breaking them. much of this had been avoided already by just
skipping the inline keyword in pre-c99 compilers or modes, but this
new unified solution is cleaner and may/should result in better code
generation in the default gcc configuration.
|
| |
|
|
|
|
| |
not sure why these were originally omitted..
|
|
|
|
|
| |
why does mips have to be gratuitously incompatible in every possible
imaginable way?
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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...
|
|
|
|
| |
based on patch by orc and Isaac Dunham, with some fixes.
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
based on a patch submitted by Kristian L. <email@thexception.net>
|
|
|
|
|
|
|
| |
one file was reusing another file's macro name, and many had
inconsistent underscores and application of SYS prefix, etc.
patch by Szabolcs Nagy (nsz)
|
| |
|
|
|
|
|
| |
this broke the busybox "free" utility (memory reporting) and possibly
other things like uptime.
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
patch by Isaac Dunham. matched closely (maybe not exact) to glibc's
idea of what _BSD_SOURCE should make visible.
|
| |
|
| |
|
|
|
|
| |
this is all junk, but some programs use 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
|
| |
|
|
|
|
| |
this type should never be used anyway, but some old junk uses it..
|