- 28 10月, 2022 1 次提交
-
-
由 maweiye 提交于
Signed-off-by: Nmaweiye <maweiye@huawei.com>
-
- 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:userspace musl code Team:OTHERS Feature or Bugfix:Feature Binary Source:NA PrivateCode(Yes/No):No Change-Id: I1d445ef7d16285be98b1857f4c01b94c9759daea Reviewed-on: http://mgit-tm.rnd.huawei.com/10274931Reviewed-by: Ncaoruihong 00546070 <crh.cao@huawei.com> Tested-by: Npublic jenkins <public_jenkins@notesmail.huawei.com> Reviewed-by: Nshenwei 00579521 <denny.shenwei@huawei.com>
-
- 13 9月, 2018 2 次提交
-
-
由 Rich Felker 提交于
this further reduces the number of source files which need to include libc.h and thereby be potentially exposed to libc global state and internals. this will also facilitate further improvements like adding an inline fast-path, if we want to do so later.
-
由 Rich Felker 提交于
commits leading up to this one have moved the vast majority of libc-internal interface declarations to appropriate internal headers, allowing them to be type-checked and setting the stage to limit their visibility. the ones that have not yet been moved are mostly namespace-protected aliases for standard/public interfaces, which exist to facilitate implementing plain C functions in terms of POSIX functionality, or C or POSIX functionality in terms of extensions that are not standardized. some don't quite fit this description, but are "internally public" interfacs between subsystems of libc. rather than create a number of newly-named headers to declare these functions, and having to add explicit include directives for them to every source file where they're needed, I have introduced a method of wrapping the corresponding public headers. parallel to the public headers in $(srcdir)/include, we now have wrappers in $(srcdir)/src/include that come earlier in the include path order. they include the public header they're wrapping, then add declarations for namespace-protected versions of the same interfaces and any "internally public" interfaces for the subsystem they correspond to. along these lines, the wrapper for features.h is now responsible for the definition of the hidden, weak, and weak_alias macros. this means source files will no longer need to include any special headers to access these features. over time, it is my expectation that the scope of what is "internally public" will expand, reducing the number of source files which need to include *_impl.h and related headers down to those which are actually implementing the corresponding subsystems, not just using them.
-
- 10 1月, 2018 1 次提交
-
-
由 Jens Gustedt 提交于
In all cases this is just a change from two volatile int to one.
-
- 22 4月, 2015 1 次提交
-
-
由 Rich Felker 提交于
the leak was found by static analysis (reported by Alexander Monakov), not tested/observed, but seems to have occured both when failing due to O_EXCL, and in a race condition with O_CREAT but not O_EXCL where a semaphore by the same name was created concurrently.
-
- 04 3月, 2015 1 次提交
-
-
由 Rich Felker 提交于
the memory model we use internally for atomics permits plain loads of values which may be subject to concurrent modification without requiring that a special load function be used. since a compiler is free to make transformations that alter the number of loads or the way in which loads are performed, the compiler is theoretically free to break this usage. the most obvious concern is with atomic cas constructs: something of the form tmp=*p;a_cas(p,tmp,f(tmp)); could be transformed to a_cas(p,*p,f(*p)); where the latter is intended to show multiple loads of *p whose resulting values might fail to be equal; this would break the atomicity of the whole operation. but even more fundamental breakage is possible. with the changes being made now, objects that may be modified by atomics are modeled as volatile, and the atomic operations performed on them by other threads are modeled as asynchronous stores by hardware which happens to be acting on the request of another thread. such modeling of course does not itself address memory synchronization between cores/cpus, but that aspect was already handled. this all seems less than ideal, but it's the best we can do without mandating a C11 compiler and using the C11 model for atomics. in the case of pthread_once_t, the ABI type of the underlying object is not volatile-qualified. so we are assuming that accessing the object through a volatile-qualified lvalue via casts yields volatile access semantics. the language of the C standard is somewhat unclear on this matter, but this is an assumption the linux kernel also makes, and seems to be the correct interpretation of the standard.
-
- 27 6月, 2013 3 次提交
-
-
由 Rich Felker 提交于
-
由 Rich Felker 提交于
-
由 Rich Felker 提交于
fstat should not fail under normal circumstances, so this fix is mostly theoretical.
-
- 01 10月, 2012 2 次提交
-
-
由 Rich Felker 提交于
also fix one minor bug: failure to free the early-reserved slot when the semaphore later found to already be mapped.
-
由 Rich Felker 提交于
this function was overly complicated and not even obviously correct. avoid using openat/linkat just like in shm_open, and instead expand pathname using code shared with shm_open. remove bogus (and dangerous, with priorities) use of spinlocks. this commit also heavily streamlines the code and ensures there are no failure cases that can happen after a new semaphore has been created in the filesystem, since that case is unreportable.
-
- 30 9月, 2012 2 次提交
-
-
由 Rich Felker 提交于
this did not matter because we don't yet treat process-shared special. when private futex support is added, however, it will matter.
-
由 Rich Felker 提交于
-
- 27 6月, 2011 1 次提交
-
-
由 Rich Felker 提交于
-
- 11 3月, 2011 2 次提交
-
-
由 Rich Felker 提交于
-
由 Rich Felker 提交于
multiple opens of the same named semaphore must return the same pointer, and only the last close can unmap it. thus the ugly global state keeping track of mappings. the maximum number of distinct named semaphores that can be opened is limited sufficiently small that the linear searches take trivial time, especially compared to the syscall overhead of these functions.
-
- 04 3月, 2011 1 次提交
-
-
由 Rich Felker 提交于
-