- 09 8月, 2013 3 次提交
-
-
由 Rich Felker 提交于
this commit does not add versioning support; it merely fixes incorrect lookups of symbols in libraries that contain versioned symbols. previously, the version information was completely ignored, and empirically this seems to have resulted in the oldest version being chosen, but I am uncertain if that behavior was even reliable. the new behavior being introduced is to completely ignore symbols which are marked "hidden" (this seems to be the confusing nomenclature for non-current-version) when versioning is present. this should solve all problems related to libraries with symbol versioning as long as all binaries involved are up-to-date (compatible with the latest-version symbols), and it's the needed behavior for dlsym under all circumstances.
-
由 rofl0r 提交于
-
由 rofl0r 提交于
-
- 08 8月, 2013 1 次提交
-
-
由 Rich Felker 提交于
at this point, it is just the common base charset equivalent to Windows CP 950, with no further extensions. HKSCS and possibly other supersets will be added later. other aliases may need to be added too.
-
- 07 8月, 2013 2 次提交
-
-
由 Rich Felker 提交于
the (obsolete) standard allows either 0 or 1 for the decimal point location in this case, but since the number of zero digits returned in the output string (in this implementation) is one more than the number of digits the caller requested, it makes sense for the decimal point to be logically "after" the first digit. in a sense, this change goes with the previous commit which fixed the value of the decimal point location for non-zero inputs.
-
由 Rich Felker 提交于
these functions are obsolete and have no modern standard. the text in SUSv2 is highly ambiguous, specifying that "negative means to the left of the returned digits", which suggested to me that 0 would mean to the right of the first digit. however, this does not agree with historic practice, and the Linux man pages are more clear, specifying that a negative value means "that the decimal point is to the left of the start of the string" (in which case, 0 would mean the start of the string, in accordance with historic practice).
-
- 06 8月, 2013 1 次提交
-
-
由 Rich Felker 提交于
like for other character sets, stateful iso-2022 form is not supported yet but everything else should work. all charset aliases are treated the same, as Windows codepage 949, because reportedly the EUC-KR charset name is in widespread (mis?)usage in email and on the web for data which actually uses the extended characters outside the standard 93x94 grid. this could easily be changed if desired. the principle of this converter for handling the giant bulk of rare Hangul syllables outside of the standard KS X 1001 93x94 grid is the same as the GB18030 converter's treatment of non-explicitly-coded Unicode codepoints: sequences in the extension range are mapped to an integer index N, and the converter explicitly computes the Nth Hangul syllable not explicitly encoded in the character map. empirically, this requires at most 7 passes over the grid. this approach reduces the table size required for Korean legacy encodings from roughly 44k to 17k and should have minimal performance impact on real-world text conversions since the "slow" characters are rare. where it does have impact, the cost is merely a large constant time factor.
-
- 04 8月, 2013 3 次提交
-
-
由 Rich Felker 提交于
unblocking it in the pthread_once init function is not sufficient, since multiple threads, some of them with the signal blocked, could already exist before this is called; timers started from such threads would be non-functional.
-
由 Rich Felker 提交于
this is needed for reused threads in the SIGEV_THREAD timer notification system, and could be reused elsewhere in the future if needed, though it should be refactored for such use. for static linking, __init_tls.c is simply modified to export the TLS info in a structure with external linkage, rather than using statics. this perhaps makes the code more clear, since the statics were poorly named for statics. the new __reset_tls.c is only linked if it is used. for dynamic linking, the code is in dynlink.c. sharing code with __copy_tls is not practical since __reset_tls must also re-zero thread-local bss.
-
由 Rich Felker 提交于
1. the thread result field was reused for storing a kernel timer id, but would be overwritten if the application code exited or cancelled the thread. 2. low pointer values were used as the indicator that the timer id is a kernel timer id rather than a thread id. this is not portable, as mmap may return low pointers on some conditions. instead, use the fact that pointers must be aligned and kernel timer ids must be non-negative to map pointers into the negative integer space. 3. signals were not blocked until after the timer thread started, so a race condition could allow a signal handler to run in the timer thread when it's not supposed to exist. this is mainly problematic if the calling thread was the only thread where the signal was unblocked and the signal handler assumes it runs in that thread.
-
- 03 8月, 2013 15 次提交
-
-
由 Rich Felker 提交于
-
由 Rich Felker 提交于
this is another case of the kernel syscall failing to support flags where it needs to, leading to horrible workarounds in userspace. this time the workaround requires changing uid/gid, and that's not safe to do in the current process. in the worst case, kernel resource limits might prevent recovering the original values, and then there would be no way to safely return. so, use the safe but horribly inefficient alternative: forking. clone is used instead of fork to suppress signals from the child. fortunately this worst-case code is only needed when effective and real ids mismatch, which mainly happens in suid programs.
-
由 Rich Felker 提交于
it turns out Linux is buggy for faccessat, just like fchmodat: the kernel does not actually take a flags argument. so we're going to have to emulate it there.
-
由 Rich Felker 提交于
-
由 Rich Felker 提交于
this is mainly for ABI compat purposes.
-
由 Rich Felker 提交于
this change is to align with a change in the glibc interface.
-
由 Rich Felker 提交于
patch by nsz. the actual object the caller has storing the tree root has type void *, so accessing it as struct node * is not valid. instead, simply access the value, move it to a temporary of the appropriate type and work from there, then move the result back.
-
由 Rich Felker 提交于
check in configure to be polite (failing early if we're going to fail) and in vfprintf.c since that is the point at which a mismatching type would be extremely dangerous.
-
由 Rich Felker 提交于
it was already declared in stdlib.h, but not defined anywhere.
-
由 Rich Felker 提交于
in several places, _BSD_SOURCE was not even implying POSIX, resulting in it being subtractive rather than additive (compared to the default features).
-
由 Rich Felker 提交于
this is a nonstandard extension.
-
由 Rich Felker 提交于
-
由 Rich Felker 提交于
on newer kernels, fchdir and fstat work anyway. this same fix should be applied to any other syscalls that are similarly affected. with this change, the current definitions of O_SEARCH and O_EXEC as O_PATH are mostly conforming to POSIX requirements. the main remaining issue is that O_NOFOLLOW has different semantics.
-
由 Rich Felker 提交于
I intend to add more Linux workarounds that depend on using these pathnames, and some of them will be in "syscall" functions that, from an anti-bloat standpoint, should not depend on the whole snprintf framework.
-
由 Rich Felker 提交于
previously, the AT_SYMLINK_NOFOLLOW flag was ignored, giving dangerously incorrect behavior -- the target of the symlink had its modes changed to the modes (usually 0777) intended for the symlink). this issue was amplified by the fact that musl provides lchmod, as a wrapper for fchmodat, which some archival programs take as a sign that symlink modes are supported and thus attempt to use. emulating AT_SYMLINK_NOFOLLOW was a difficult problem, and I originally believed it could not be solved, at least not without depending on kernels newer than 3.5.x or so where O_PATH works halfway well. however, it turns out that accessing O_PATH file descriptors via their pseudo-symlink entries in /proc/self/fd works much better than trying to use the fd directly, and works even on older kernels. moreover, the kernel has permanently pegged these references to the inode obtained by the O_PATH open, so there should not be race conditions with the file being moved, deleted, replaced, etc.
-
- 02 8月, 2013 10 次提交
-
-
由 Rich Felker 提交于
this is the modern way, and the only way that makes any sense. glibc has this complicated mechanism with RPATH and RUNPATH that controls whether RPATH is processed before or after LD_LIBRARY_PATH, presumably to support legacy binaries, but there is no compelling reason to support this, and better behavior is obtained by just fixing the search order.
-
由 Rich Felker 提交于
this is all useless but part of the API, which is part of the _GNU_SOURCE API, so something may need them.
-
由 Rich Felker 提交于
this fixes an oversight in the previous commit.
-
由 Rich Felker 提交于
previously, errno could be meaningless when the caller wrote it to the dlerror string or stderr. try to make it meaningful. also, fix incorrect check for over-long program headers and instead actually support them by allocating memory if needed.
-
由 Rich Felker 提交于
this can only happen for invalid library files, but they were not detected reliably because the variable was uninitialized.
-
由 Rich Felker 提交于
the access function cannot be used to check for existence, because it operates using real uid/gid rather than effective to determine accessibility; this matters for the non-final path components. instead, use stat. failure of stat is success if only the final component is missing (ENOENT) and otherwise is failure.
-
由 Rich Felker 提交于
-
由 Rich Felker 提交于
also refactor mkdtemp based on new shared temp code, removing dependency on the deprecated mktemp, whose behavior made this logic more difficult.
-
由 Rich Felker 提交于
the concept of both versions is the same; they differ only in details. for long runs, they use "rep movsl" or "rep movsq", and for small runs, they use a trick, writing from both ends towards the middle, that reduces the number of branches needed. in addition, if memset is called multiple times with the same length, all branches will be predicted; there are no loops. for larger runs, there are likely faster approaches than "rep", at least on some cpu models. for 32-bit, it's unlikely that there is any faster approach that does not require non-baseline instructions; doing anything fancier would require inspecting cpu capabilities. for 64-bit, there may very well be faster versions that work on all models; further optimization could be explored in the future. with these changes, memset is anywhere between 50% faster and 6 times faster, depending on the cpu model and the length and alignment of the destination buffer.
-
由 Rich Felker 提交于
-
- 01 8月, 2013 5 次提交
-
-
由 Rich Felker 提交于
the original motivation for this patch was that qemu (and possibly other syscall emulators) nop out madvise, resulting in an infinite loop. however, there is another benefit to this change: madvise may actually undo an explicit madvise the application intended for its stack, whereas the mremap operation is a true nop. the logic here is that mremap must fail if it cannot resize the mapping in-place, and the caller knows that it cannot resize in-place because it knows the next page of virtual memory is already occupied.
-
由 Rich Felker 提交于
one of the arguments to memcmp may be shorter than the length l-3, and memcmp is under no obligation not to access past the first byte that differs. instead use strncmp which conveys the correct semantics. the performance difference is negligible here and since the code is only use for shared libc, both functions are already linked anyway.
-
由 Rich Felker 提交于
the dev/inode for the main app and the dynamic linker ("interpreter") are not available, so the subsequent checks don't work. in general we don't want to make exact string matches to existing libraries prevent loading new ones, since this breaks loading upgraded modules in module-loading systems. so instead, special-case it. the motivation for this fix is that calling dlopen on the names returned by dl_iterate_phdr or walking the link map (obtained by dlinfo) seem to be the only methods available to an application to actually get a list of open dso handles.
-
由 Rich Felker 提交于
reject elf files which are not ET_EXEC/ET_DYN type as bad exec format, and reject ET_EXEC files when they cannot be loaded at the correct address, since they are not relocatable at runtime. the main practical benefit of this is to make dlopen of the main program fail rather than producing an unsafe-to-use handle.
-
由 Rich Felker 提交于
-