| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
note that none of these are implemented, and programs depending on
them may break... patch by sh4rm4
|
|
patches by sh4rm4, presumably needed to make gdb or some similar junk
happy...
|
|
...and still be valid in #if directives.
|
|
|
|
issue reported by nsz, but it's actually not just pedantic. the
functions can take input of any arithmetic type, including floating
point, and the behavior needs to be as if the conversion implicit in
the function call took place.
|
|
the changes to syscall_ret are mostly no-ops in the generated code,
just cleanup of type issues and removal of some implementation-defined
behavior. the one exception is the change in the comparison value,
which is fixed so that 0xf...f000 (which in principle could be a valid
return value for mmap, although probably never in reality) is not
treated as an error return.
|
|
casting to int would not be correct because high bits could be lost.
mapping the high bits down onto low bits would be costlier in the
common case where the result is just used in a conditional. changing
the type of the bit array elements to int would permute the order of
the bit array on 64-bit big endian systems, so that's not an option
either.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
this is a case of poorly written man pages not matching the actual
implementation, and why i hate implementing nonstandard interfaces
with no actual documentation of how they're intended to work.
|
|
this bug was introduced in a recent patch. the problem we're working
around is that broken GNU software wants to use "struct siginfo"
rather than "siginfo_t", but "siginfo" is not in the reserved
namespace and thus not legal for the standard header to use.
|
|
at the same time, make struct statfs match the traditional definition
and make it more useful, especially the fsid_t stuff.
|
|
|
|
|
|
really wchar_t should never vary, but the ARM EABI defines it as an
unsigned 32-bit int instead of a signed one, and gcc follows this
nonsense. thus, to give a conformant environment, we have to follow
(otherwise L""[0] and L'\0' would be 0U rather than 0, but the
application would be unaware due to a mismatched definition for
WCHAR_MIN and WCHAR_MAX, and Bad Things could happen with respect to
signed/unsigned comparisons, promotions, etc.).
fortunately no rules are imposed by the C standard on the relationship
between wchar_t and wint_t, and WEOF has type wint_t, so we can still
make wint_t always-signed and use -1 for WEOF.
|
|
|
|
|
|
|
|
|
|
several things are changed. first, i have removed the old __uniclone
function signature and replaced it with the "standard" linux
__clone/clone signature. this was necessary to expose clone to
applications anyway, and it makes it easier to port __clone to new
archs, since it's now testable independently of pthread_create.
secondly, i have removed all references to the ugly ldt descriptor
structure (i386 only) from the c code and pthread structure. in places
where it is needed, it is now created on the stack just when it's
needed, in assembly code. thus, the i386 __clone function takes the
desired thread pointer as its argument, rather than an ldt descriptor
pointer, just like on all other sane archs. this should not affect
applications since there is really no way an application can use clone
with threads/tls in a way that doesn't horribly conflict with and
clobber the underlying implementation's use. applications are expected
to use clone only for creating actual processes, possibly with new
namespace features and whatnot.
|
|
|
|
previous fix was backwards and propagated the wrong type rather than
the right one...
|
|
|
|
|
|
|
|
actually these are just weak aliases for the normal locking versions
right now, and they will probably stay that way since making them
lock-free without slowing down the normal versions would require
significant code duplication for no benefit.
|
|
programs that use this tend to horribly botch international text
support, so it's questionable whether we want to support it even in
the long term... for now, it's just a dummy that calls strcmp.
|
|
|
|
some features are not yet supported, and only minimal testing has been
performed. should be considered experimental at this point.
|
|
testing so far has been minimal. may need further work.
|
|
not heavily tested, but it seems to be correct, including the odd
behavior that seeking is in terms of wide character count. this
precludes any simple buffering, so we just make the stream unbuffered.
|
|
this is the first attempt, and may have bugs. only minimal testing has
been performed.
|
|
|
|
1 is too small if int is 32-bit but unsigned long is 64-bit. be
explicit and use 1UL.
|
|
no sense bloating apps with a function call for an equality comparison...
|
|
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.
|
|
this is necessary to avoid build errors if feature test macros are not
properly defined when including ucontext.h
|
|
|
|
STREAMS are utterly useless as far as I can tell, but some software
was apparently broken by the presence of stropts.h but lack of macros
it's supposed to define...
|
|
hopefully this resolves the rest of the issues with hideously
nonportable hacks in programs that use gnulib.
|
|
this is a really ugly and backwards function, but its presence will
prevent lots of broken gnulib software from trying to define its own
version of fpurge and thereby failing to build or worse.
|
|
|
|
|
|
|
|
|
|
|
