- 19 8月, 2021 1 次提交
-
-
由 Caoruihong 提交于
Signed-off-by: NCaoruihong <crh.cao@huawei.com> Change-Id: I36ed85c6af3b80f780f26c047e096fe861b9e8c3
-
- 11 6月, 2021 1 次提交
-
-
由 Caoruihong 提交于
isolate changes, keep orignal musl sources clean. Signed-off-by: NCaoruihong <crh.cao@huawei.com> Change-Id: Id7f3a5109771f93d397e30febba36e09ddaf4f36
-
- 11 3月, 2021 1 次提交
-
-
由 mamingshuai 提交于
-
- 09 9月, 2020 1 次提交
-
-
由 wenjun 提交于
-
- 17 8月, 2020 1 次提交
-
-
由 c00346986 提交于
Description:kernelspace musl code Team:OTHERS Feature or Bugfix:Feature Binary Source:NA PrivateCode(Yes/No):No Change-Id: I99874a7c570b7d22b4a3d34840260eb48ea3ffa1 Reviewed-on: http://mgit-tm.rnd.huawei.com/10276995Reviewed-by: Nshenwei 00579521 <denny.shenwei@huawei.com> Tested-by: Npublic jenkins <public_jenkins@notesmail.huawei.com>
-
- 29 10月, 2019 1 次提交
-
-
由 Rich Felker 提交于
a _REDIR_TIME64 macro is introduced, which the arch's alltypes.h is expected to define, to control redirection of symbol names for interfaces that involve time_t and derived types. this ensures that object files will only be linked to libc interfaces matching the ABI whose headers they were compiled against. along with time32 compat shims, which will be introduced separately, the redirection also makes it possible for a single libc (static or shared) to be used with object files produced with either the old (32-bit time_t) headers or the new ones after 64-bit time_t switchover takes place. mixing of such object files (or shared libraries) in the same program will also be possible, but must be done with care; ABI between libc and a consumer of the libc interfaces is guaranteed to match by the the symbol name redirection, but pairwise ABI between consumers of libc that define interfaces between each other in terms of time_t is not guaranteed to match. this change adds a dependency on an additional "GNU C" feature to the public headers for existing 32-bit archs, which is generally undesirable; however, the feature is one which glibc has depended on for a long time, and thus which any viable alternative compiler is going to need to provide. 64-bit archs are not affected, nor will future 32-bit archs be, regardless of whether they are "new" on the kernel side (e.g. riscv32) or just newly-added (e.g. a new sparc or xtensa port). the same applies to newly-added ABIs for existing machine-level archs.
-
- 21 10月, 2016 1 次提交
-
-
由 Rich Felker 提交于
reported and changes suggested by Daniel Sabogal.
-
- 04 7月, 2016 1 次提交
-
-
由 Rich Felker 提交于
placing the opening brace on the same line as the struct keyword/tag is the style I prefer and seems to be the prevailing practice in more recent additions. these changes were generated by the command: find include/ arch/*/bits -name '*.h' \ -exec sed -i '/^struct [^;{]*$/{N;s/\n/ /;}' {} + and subsequently checked by hand to ensure that the regex did not pick up any false positives.
-
- 11 9月, 2014 1 次提交
-
-
由 Rich Felker 提交于
the vast majority of these failures seem to have been oversights at the time _BSD_SOURCE was added, or perhaps shortly afterward. the one which may have had some reason behind it is omission of setpgrp from the _BSD_SOURCE feature profile, since the standard setpgrp interface conflicts with a legacy (pre-POSIX) BSD interface by the same name. however, such omission is not aligned with our general policy in this area (for example, handling of similar _GNU_SOURCE cases) and should not be preserved.
-
- 07 9月, 2014 1 次提交
-
-
由 Rich Felker 提交于
based on patch by Jens Gustedt for inclusion with C11 threads implementation, but committed separately since it's independent of threads.
-
- 07 1月, 2014 1 次提交
-
-
由 Rich Felker 提交于
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.
-
- 25 11月, 2013 1 次提交
-
-
由 Rich Felker 提交于
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.)
-
- 07 10月, 2013 1 次提交
-
-
由 Szabolcs Nagy 提交于
-
- 25 7月, 2013 1 次提交
-
-
由 Szabolcs Nagy 提交于
added in linux-v3.10 commit 1ff3c9677bff7e468e0c487d0ffefe4e901d33f4
-
- 08 6月, 2013 2 次提交
-
-
由 Rich Felker 提交于
arguably CLOCK_MONOTONIC should be redirected to CLOCK_BOOTTIME with a fallback for old kernels that don't support it, since Linux's CLOCK_BOOTTIME semantics seem to match the spirit of the POSIX requirements for CLOCK_MONOTONIC better than Linux's version of CLOCK_MONOTONIC does. however, this is a change that would require further discussion and research, so for now, I'm simply making them all available.
-
由 Rich Felker 提交于
originally it was right on 32-bit archs and wrong on 64-bit, but after recent changes it was wrong everywhere. with this commit, it's now right everywhere.
-
- 07 6月, 2013 1 次提交
-
-
由 Rich Felker 提交于
defining tm_gmtoff and tm_zone as macros was breaking some application code that used these names for its own purposes.
-
- 02 4月, 2013 1 次提交
-
-
由 rofl0r 提交于
-
- 19 1月, 2013 1 次提交
-
-
由 Rich Felker 提交于
the historical mess of having different definitions for C and C++ comes from the historical C definition as (void *)0 and the fact that (void *)0 can't be used in C++ because it does not convert to other pointer types implicitly. however, using plain 0 in C++ exposed bugs in C++ programs that call variadic functions with NULL as an argument and (wrongly; this is UB) expect it to arrive as a null pointer. on 64-bit machines, the high bits end up containing junk. glibc dodges the issue by using a GCC extension __null to define NULL; this is observably non-conforming because a conforming application could observe the definition of NULL via stringizing and see that it is neither an integer constant expression with value zero nor such an expression cast to void. switching to 0L eliminates the issue and provides compatibility with broken applications, since on all musl targets, long and pointers have the same size, representation, and argument-passing convention. we could maintain separate C and C++ definitions of NULL (i.e. just use 0L on C++ and use (void *)0 on C) but after careful analysis, it seems extremely difficult for a C program to even determine whether NULL has integer or pointer type, much less depend in subtle, unintentional ways, on whether it does. C89 seems to have no way to make the distinction. on C99, the fact that (int)(void *)0 is not an integer constant expression, along with subtle VLA/sizeof semantics, can be used to make the distinction, but many compilers are non-conforming and give the wrong result to this test anyway. on C11, _Generic can trivially make the distinction, but it seems unlikely that code targetting C11 would be so backwards in caring which definition of NULL an implementation uses. as such, the simplest path of using the same definition for NULL in both C and C++ was chosen. the #undef directive was also removed so that the compiler can catch and give a warning or error on redefinition if buggy programs have defined their own versions of NULL prior to inclusion of standard headers.
-
- 05 1月, 2013 1 次提交
-
-
由 rofl0r 提交于
-
- 08 9月, 2012 1 次提交
-
-
由 Rich Felker 提交于
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.
-
- 07 9月, 2012 1 次提交
-
-
由 Rich Felker 提交于
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.
-
- 14 6月, 2012 3 次提交
-
-
由 Rich Felker 提交于
-
由 Rich Felker 提交于
stime is not _XOPEN_SOURCE, and some functions were missing with _BSD_SOURCE..
-
由 Rich Felker 提交于
-
- 23 5月, 2012 1 次提交
-
-
由 Rich Felker 提交于
patch by Isaac Dunham. matched closely (maybe not exact) to glibc's idea of what _BSD_SOURCE should make visible.
-
- 19 4月, 2012 1 次提交
-
-
由 Rich Felker 提交于
- 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
-
- 07 2月, 2012 1 次提交
-
-
由 Rich Felker 提交于
this should be everything except for some functions where the non-_l version isn't even implemented yet (mainly some non-ISO-C wcs* functions).
-
- 26 9月, 2011 1 次提交
-
-
由 Rich Felker 提交于
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.
-
- 14 9月, 2011 1 次提交
-
-
由 Rich Felker 提交于
-
- 16 2月, 2011 1 次提交
-
-
由 Rich Felker 提交于
-
- 15 2月, 2011 1 次提交
-
-
由 Rich Felker 提交于
-
- 12 2月, 2011 1 次提交
-
-
由 Rich Felker 提交于
-