| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
based on patch by orc and Isaac Dunham, with some details fixed.
|
| |
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
| |
lots of broken programs expect this, and it's gotten to the point of
being a troubleshooting FAQ topic. best to just fix it.
|
| |
|
|
|
|
|
|
|
|
| |
i made a best attempt, but the intended semantics of this function are
fundamentally contradictory. there is no consistent way to handle
ownership of locks when forking a multi-threaded process. the code
could have worked by accident for programs that only used normal
mutexes and nothing else (since they don't actually store or care
about their owner), but that's about it. broken-by-design interfaces
that aren't even in glibc (only solaris) don't belong in musl.
|
| | |
|
| | |
|
| |
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
musl does not support legacy 32-bit-off_t whatsoever. off_t is always
64 bit, and correct programs that use off_t and the standard functions
will just work out of the box. (on glibc, they would require
-D_FILE_OFFSET_BITS=64 to work.) however, some programs instead define
_LARGEFILE64_SOURCE and use alternate versions of all the standard
types and functions with "64" appended to their names.
we do not want code to actually get linked against these functions
(it's ugly and inconsistent), so macros are used instead of prototypes
with weak aliases in the library itself. eventually the weak aliases
may be added at the library level for the sake of using code that was
originally built against glibc, but the macros will still be the
desired solution in the headers.
|
| |
|
|
|
| |
I actually wrote these a month ago but forgot to integrate them. ugly,
probably-harmful-to-use functions, but some legacy apps want them...
|
| | |
|
| | |
|
| |
|
|
|
|
| |
- 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 is a "nonstandard" function that was "rejected" by POSIX, but
nonetheless had its behavior documented in the POSIX rationale for
fork. it's present on solaris and possibly some other systems, and
duplicates the whole calling process, not just a single thread. glibc
does not have this function. it should not be used in programs
intending to be portable, but may be useful for testing,
checkpointing, etc. and it's an interesting (and quite small) example
of the usefulness of the __synccall framework originally written to
work around deficiencies in linux's setuid syscall.
|
| |
|
|
|
| |
the old versions worked, but conflicted with programs which declared
their own prototypes and generated warnings with some versions of gcc.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
