| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
| |
these have not been heavily tested, but they should work as described
in the old standards. probably broken for non-finite values...
|
| |
|
|
| |
this type should never be used anyway, but some old junk uses it..
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
based on patch by Jeremy Huntwork
|
| |
|
|
| |
patch by Jeremy Huntwork
|
| | |
|
| | |
|
| |
|
|
| |
this is a nonstandard junk header anyway, so just do what apps expect..
|
| |
|
|
|
| |
based on patch by sh4rm4. these functions are deprecated; futimens and
utimensat should be used instead in new programs.
|
| | |
|
| | |
|
| |
|
|
| |
patch by Arvid Picciani (aep)
|
| |
|
|
|
| |
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.
|
