about summary refs log tree commit diff
path: root/src/internal
Commit message (Collapse)AuthorAgeFilesLines
* remove cruft for libc struct accessor function and broken visibilityRich Felker2015-04-221-14/+0
| | | | | | | | | these were hacks to work around toolchains that could not properly optimize PIC accesses based on visibility and would generate GOT lookups even for hidden data, which broke the old dynamic linker. since commit f3ddd173806fd5c60b3f034528ca24542aecc5b9 it no longer matters; the dynamic linker does not assume accessibility of this data until stage 3.
* add optional global visibility overrideRich Felker2015-04-191-0/+40
| | | | | | | | | | | | this is implemented via the build system and does not affect source files. the idea is to use protected or hidden visibility to prevent the compiler from pessimizing function calls within a shared (or position-independent static) libc in the form of overhead setting up for a call through the PLT. the ld-time symbol binding via the -Bsymbolic-functions option already optimized out the PLT itself, but not the code in the caller needed to support a call through the PLT. on some archs this overhead can be substantial; on others it's trivial.
* make dlerror state and message thread-local and dynamically-allocatedRich Felker2015-04-181-0/+2
| | | | | | | | | this fixes truncation of error messages containing long pathnames or symbol names. the dlerror state was previously required by POSIX to be global. the resolution of bug 97 relaxed the requirements to allow thread-safe implementations of dlerror with thread-local state and message buffer.
* add missing 'void' in prototypes of internal pthread functionsAlexander Monakov2015-04-181-6/+6
|
* fix inconsistent visibility for internal syscall symbolsRich Felker2015-04-1411-1/+11
|
* use hidden visibility for i386 asm-internal __vsyscall symbolRich Felker2015-04-141-0/+2
| | | | | otherwise the call instruction in the inline syscall asm results in textrels without ld-time binding.
* remove remnants of support for running in no-thread-pointer modeRich Felker2015-04-131-2/+1
| | | | | | | | | | | | | since 1.1.0, musl has nominally required a thread pointer to be setup. most of the remaining code that was checking for its availability was doing so for the sake of being usable by the dynamic linker. as of commit 71f099cb7db821c51d8f39dfac622c61e54d794c, this is no longer necessary; the thread pointer is now valid before any libc code (outside of dynamic linker bootstrap functions) runs. this commit essentially concludes "phase 3" of the "transition path for removing lazy init of thread pointer" project that began during the 1.1.0 release cycle.
* dynamic linker bootstrap overhaulRich Felker2015-04-131-0/+57
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | this overhaul further reduces the amount of arch-specific code needed by the dynamic linker and removes a number of assumptions, including: - that symbolic function references inside libc are bound at link time via the linker option -Bsymbolic-functions. - that libc functions used by the dynamic linker do not require access to data symbols. - that static/internal function calls and data accesses can be made without performing any relocations, or that arch-specific startup code handled any such relocations needed. removing these assumptions paves the way for allowing libc.so itself to be built with stack protector (among other things), and is achieved by a three-stage bootstrap process: 1. relative relocations are processed with a flat function. 2. symbolic relocations are processed with no external calls/data. 3. main program and dependency libs are processed with a fully-functional libc/ldso. reduction in arch-specific code is achived through the following: - crt_arch.h, used for generating crt1.o, now provides the entry point for the dynamic linker too. - asm is no longer responsible for skipping the beginning of argv[] when ldso is invoked as a command. - the functionality previously provided by __reloc_self for heavily GOT-dependent RISC archs is now the arch-agnostic stage-1. - arch-specific relocation type codes are mapped directly as macros rather than via an inline translation function/switch statement.
* redesign and simplify vmlock systemRich Felker2015-04-101-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | this global lock allows certain unlock-type primitives to exclude mmap/munmap operations which could change the identity of virtual addresses while references to them still exist. the original design mistakenly assumed mmap/munmap would conversely need to exclude the same operations which exclude mmap/munmap, so the vmlock was implemented as a sort of 'symmetric recursive rwlock'. this turned out to be unnecessary. commit 25d12fc0fc51f1fae0f85b4649a6463eb805aa8f already shortened the interval during which mmap/munmap held their side of the lock, but left the inappropriate lock design and some inefficiency. the new design uses a separate function, __vm_wait, which does not hold any lock itself and only waits for lock users which were already present when it was called to release the lock. this is sufficient because of the way operations that need to be excluded are sequenced: the "unlock-type" operations using the vmlock need only block mmap/munmap operations that are precipitated by (and thus sequenced after) the atomic-unlock they perform while holding the vmlock. this allows for a spectacular lack of synchronization in the __vm_wait function itself.
* add aarch64 portSzabolcs Nagy2015-03-111-0/+13
| | | | | | | | | | This adds complete aarch64 target support including bigendian subarch. Some of the long double math functions are known to be broken otherwise interfaces should be fully functional, but at this point consider this port experimental. Initial work on this port was done by Sireesh Tripurari and Kevin Bortis.
* math: add dummy implementations of 128 bit long double functionsSzabolcs Nagy2015-03-111-0/+14
| | | | | | | | This is in preparation for the aarch64 port only to have the long double math symbols available on ld128 platforms. The implementations should be fixed up later once we have proper tests for these functions. Added bigendian handling for ld128 bit manipulations too.
* copy the dtv pointer to the end of the pthread struct for TLS_ABOVE_TP archsSzabolcs Nagy2015-03-111-0/+1
| | | | | | | | | | | | | | | | | | | | There are two main abi variants for thread local storage layout: (1) TLS is above the thread pointer at a fixed offset and the pthread struct is below that. So the end of the struct is at known offset. (2) the thread pointer points to the pthread struct and TLS starts below it. So the start of the struct is at known (zero) offset. Assembly code for the dynamic TLSDESC callback needs to access the dynamic thread vector (dtv) pointer which is currently at the front of the pthread struct. So in case of (1) the asm code needs to hard code the offset from the end of the struct which can easily break if the struct changes. This commit adds a copy of the dtv at the end of the struct. New members must not be added after dtv_copy, only before it. The size of the struct is increased a bit, but there is opportunity for size optimizations.
* make all objects used with atomic operations volatileRich Felker2015-03-033-20/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* factor cancellation cleanup push/pop out of futex __timedwait functionRich Felker2015-03-021-1/+2
| | | | | | | | | | | | | previously, the __timedwait function was optionally a cancellation point depending on whether it was passed a pointer to a cleaup function and context to register. as of now, only one caller actually used such a cleanup function (and it may face removal soon); most callers either passed a null pointer to disable cancellation or a dummy cleanup function. now, __timedwait is never a cancellation point, and __timedwait_cp is the cancellable version. this makes the intent of the calling code more obvious and avoids ugly dummy functions and long argument lists.
* add IEEE binary128 long double support to floatscanSzabolcs Nagy2015-02-091-1/+9
| | | | | | | | | | | | | | | | | just defining the necessary constants: LD_B1B_MAX is 2^113 - 1 in base 10^9 KMAX is 2048 so the x array can hold up to 18432 decimal digits (the worst case is converting 2^-16495 = 5^16495 * 10^-16495 to binary, it requires the processing of int(log10(5)*16495)+1 = 11530 decimal digits after discarding the leading zeros, the conversion requires some headroom in x, but KMAX is more than enough for that) However this code is not optimal on archs with IEEE binary128 long double because the arithmetics is software emulated (on all such platforms as far as i know) which means big and slow strtod.
* remove cruft from x86_64 syscall.hSzabolcs Nagy2015-02-071-0/+3
| | | | | | | x86_64 syscall.h defined some musl internal syscall names and made them public. These defines were already moved to src/internal/syscall.h (except for SYS_fadvise which is added now) so the cruft in x86_64 syscall.h is not needed.
* add FUTEX_PRIVATE macro to internal futex.hRich Felker2015-01-151-0/+2
|
* provide CMPLX macros in implementation-internal libm.hRich Felker2014-12-171-0/+12
| | | | | | this avoids assuming the presence of C11 macro definitions in the public complex.h, which need changes potentially incompatible with the way these macros are being used internally.
* unify non-inline version of syscall code across archsRich Felker2014-11-221-0/+10
| | | | | | | | | | | | | | except powerpc, which still lacks inline syscalls simply because nobody has written the code, these are all fallbacks used to work around a clang bug that probably does not exist in versions of clang that can compile musl. however, it's useful to have the generic non-inline code anyway, as it eases the task of porting to new archs: writing inline syscall code is now optional. this approach could also help support compilers which don't understand inline asm or lack support for the needed register constraints. mips could not be unified because it has special fixup code for broken layout of the kernel's struct stat.
* fix overflow corner case in strtoul-family functionsRich Felker2014-09-161-0/+1
| | | | | | | | incorrect behavior occurred only in cases where the input overflows unsigned long long, not just the (possibly lower) range limit for the result type. in this case, processing of the '-' sign character was not suppressed, and the function returned a value of 1 despite setting errno to ERANGE.
* add C11 thread creation and related thread functionsRich Felker2014-09-071-0/+2
| | | | | | | | | | | | | | | | | based on patch by Jens Gustedt. the main difficulty here is handling the difference between start function signatures and thread return types for C11 threads versus POSIX threads. pointers to void are assumed to be able to represent faithfully all values of int. the function pointer for the thread start function is cast to an incorrect type for passing through pthread_create, but is cast back to its correct type before calling so that the behavior of the call is well-defined. changes to the existing threads implementation were kept minimal to reduce the risk of regressions, and duplication of code that carries implementation-specific assumptions was avoided for ease and safety of future maintenance.
* fix false ownership of stdio FILEs due to tid reuseRich Felker2014-08-232-0/+2
| | | | | | | | | | | | | this is analogous commit fffc5cda10e0c5c910b40f7be0d4fa4e15bb3f48 which fixed the corresponding issue for mutexes. the robust list can't be used here because the locks do not share a common layout with mutexes. at some point it may make sense to simply incorporate a mutex object into the FILE structure and use it, but that would be a much more invasive change, and it doesn't mesh well with the current design that uses a simpler code path for internal locking and pulls in the recursive-mutex-like code when the flockfile API is used explicitly.
* fix fallback checks for kernels without private futex supportRich Felker2014-08-221-1/+1
| | | | for unknown syscall commands, the kernel produces ENOSYS, not EINVAL.
* redesign cond var implementation to fix multiple issuesRich Felker2014-08-171-5/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | the immediate issue that was reported by Jens Gustedt and needed to be fixed was corruption of the cv/mutex waiter states when switching to using a new mutex with the cv after all waiters were unblocked but before they finished returning from the wait function. self-synchronized destruction was also handled poorly and may have had race conditions. and the use of sequence numbers for waking waiters admitted a theoretical missed-wakeup if the sequence number wrapped through the full 32-bit space. the new implementation is largely documented in the comments in the source. the basic principle is to use linked lists initially attached to the cv object, but detachable on signal/broadcast, made up of nodes residing in automatic storage (stack) on the threads that are waiting. this eliminates the need for waiters to access the cv object after they are signaled, and allows us to limit wakeup to one waiter at a time during broadcasts even when futex requeue cannot be used. performance is also greatly improved, roughly double some tests. basically nothing is changed in the process-shared cond var case, where this implementation does not work, since processes do not have access to one another's local storage.
* make pointers used in robust list volatileRich Felker2014-08-171-2/+2
| | | | | | | | | | | | | | | | | | | | when manipulating the robust list, the order of stores matters, because the code may be asynchronously interrupted by a fatal signal and the kernel will then access the robust list in what is essentially an async-signal context. previously, aliasing considerations made it seem unlikely that a compiler could reorder the stores, but proving that they could not be reordered incorrectly would have been extremely difficult. instead I've opted to make all the pointers used as part of the robust list, including those in the robust list head and in the individual mutexes, volatile. in addition, the format of the robust list has been changed to point back to the head at the end, rather than ending with a null pointer. this is to match the documented kernel robust list ABI. the null pointer, which was previously used, only worked because faults during access terminate the robust list processing.
* make futex operations use private-futex mode when possibleRich Felker2014-08-151-2/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | private-futex uses the virtual address of the futex int directly as the hash key rather than requiring the kernel to resolve the address to an underlying backing for the mapping in which it lies. for certain usage patterns it improves performance significantly. in many places, the code using futex __wake and __wait operations was already passing a correct fixed zero or nonzero flag for the priv argument, so no change was needed at the site of the call, only in the __wake and __wait functions themselves. in other places, especially where the process-shared attribute for a synchronization object was not previously tracked, additional new code is needed. for mutexes, the only place to store the flag is in the type field, so additional bit masking logic is needed for accessing the type. for non-process-shared condition variable broadcasts, the futex requeue operation is unable to requeue from a private futex to a process-shared one in the mutex structure, so requeue is simply disabled in this case by waking all waiters. for robust mutexes, the kernel always performs a non-private wake when the owner dies. in order not to introduce a behavioral regression in non-process-shared robust mutexes (when the owning thread dies), they are simply forced to be treated as process-shared for now, giving correct behavior at the expense of performance. this can be fixed by adding explicit code to pthread_exit to do the right thing for non-shared robust mutexes in userspace rather than relying on the kernel to do it, and will be fixed in this way later. since not all supported kernels have private futex support, the new code detects EINVAL from the futex syscall and falls back to making the call without the private flag. no attempt to cache the result is made; caching it and using the cached value efficiently is somewhat difficult, and not worth the complexity when the benefits would be seen only on ancient kernels which have numerous other limitations and bugs anyway.
* add framework for mmap2 syscall unit to vary by archRich Felker2014-07-301-0/+4
|
* implement mo file string lookup for translationsRich Felker2014-07-261-0/+6
| | | | | | | | | | the core is based on a binary search; hash table is not used. both native and reverse-endian mo files are supported. all offsets read from the mapped mo file are checked against the mapping size to prevent the possibility of reads outside the mapping. this commit has no observable effects since there are not yet any callers to the message translation code.
* implement locale file loading and state for remaining locale categoriesRich Felker2014-07-242-0/+10
| | | | | | | | there is still no code which actually uses the loaded locale files, so the main observable effect of this commit is that calls to setlocale store and give back the names of the selected locales for the remaining categories (LC_TIME, LC_COLLATE, LC_MONETARY) if a locale file by the requested name could be loaded.
* add or1k (OpenRISC 1000) architecture portStefan Kristiansson2014-07-181-0/+13
| | | | | | | | | | | | | | | With the exception of a fenv implementation, the port is fully featured. The port has been tested in or1ksim, the golden reference functional simulator for OpenRISC 1000. It passes all libc-test tests (except the math tests that requires a fenv implementation). The port assumes an or1k implementation that has support for atomic instructions (l.lwa/l.swa). Although it passes all the libc-test tests, the port is still in an experimental state, and has yet experienced very little 'real-world' use.
* add locale frameworkRich Felker2014-07-022-3/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | this commit adds non-stub implementations of setlocale, duplocale, newlocale, and uselocale, along with the data structures and minimal code needed for representing the active locale on a per-thread basis and optimizing the common case where thread-local locale settings are not in use. at this point, the data structures only contain what is necessary to represent LC_CTYPE (a single flag) and LC_MESSAGES (a name for use in finding message translation files). representation for the other categories will be added later; the expectation is that a single pointer will suffice for each. for LC_CTYPE, the strings "C" and "POSIX" are treated as special; any other string is accepted and treated as "C.UTF-8". for other categories, any string is accepted after being truncated to a maximum supported length (currently 15 bytes). for LC_MESSAGES, the name is kept regardless of whether libc itself can use such a message translation locale, since applications using catgets or gettext should be able to use message locales libc is not aware of. for other categories, names which are not successfully loaded as locales (which, at present, means all names) are treated as aliases for "C". setlocale never fails. locale settings are not yet used anywhere, so this commit should have no visible effects except for the contents of the string returned by setlocale.
* simplify errno implementationRich Felker2014-06-101-1/+1
| | | | | | | | | | | | | | | the motivation for the errno_ptr field in the thread structure, which this commit removes, was to allow the main thread's errno to keep its address when lazy thread pointer initialization was used. &errno was evaluated prior to setting up the thread pointer and stored in errno_ptr for the main thread; subsequently created threads would have errno_ptr pointing to their own errno_val in the thread structure. since lazy initialization was removed, there is no need for this extra level of indirection; __errno_location can simply return the address of the thread's errno_val directly. this does cause &errno to change, but the change happens before entry to application code, and thus is not observable.
* fix for broken kernel side RLIM_INFINITY on mipsSzabolcs Nagy2014-05-301-0/+4
| | | | | | | | | | | | | | | | | | | | On 32 bit mips the kernel uses -1UL/2 to mark RLIM_INFINITY (and this is the definition in the userspace api), but since it is in the middle of the valid range of limits and limits are often compared with relational operators, various kernel side logic is broken if larger than -1UL/2 limits are used. So we truncate the limits to -1UL/2 in get/setrlimit and prlimit. Even if the kernel side logic consistently treated -1UL/2 as greater than any other limit value, there wouldn't be any clean workaround that allowed using large limits: * using -1UL/2 as RLIM_INFINITY in userspace would mean different infinity value for get/setrlimt and prlimit (where infinity is always -1ULL) and userspace logic could break easily (just like the kernel is broken now) and more special case code would be needed for mips. * translating -1UL/2 kernel side value to -1ULL in userspace would mean that -1UL/2 limit cannot be set (eg. -1UL/2+1 had to be passed to the kernel instead).
* break down coarse-grained 64-bit-off_t syscall remappingsRich Felker2014-05-301-4/+16
| | | | | | | | | | using the existence of SYS_stat64 as the condition for remapping other related syscalls is no longer valid, since new archs that omit the old syscalls will not have SYS_stat or SYS_stat64, but still potentially need SYS_fstat and others remapped. it would probably be possible to get by with just one or two extra conditionals, but just breaking them all down into separate conditions is robust and not significantly heavier for the preprocessor.
* fix sendfile syscall to use 64-bit off_tRich Felker2014-05-301-0/+5
| | | | | | | | | | somehow the remapping of this syscall to the 64-bit version was overlooked. the issue was found, and patch provided, by Stefan Kristiansson. presumably the reason this bug was not caught earlier is that the syscall takes a pointer to off_t rather than a value, so on little-endian systems, everything appears to work as long as the offset value fits in the low 31 bits. on big-endian systems, though, sendfile was presumably completely non-functional.
* fix sys_open macro for archs without the plain open syscallRich Felker2014-05-271-4/+4
|
* fix placement of multiple inclusion guard endif in internal syscall.hRich Felker2014-05-271-2/+2
| | | | | | this was messed up during a recent commit when the socketcall macros were moved to the common internal/syscall.h, and the following commit expanded the problem by adding more new content outside the guard.
* support kernels with no SYS_open syscall, only SYS_openatRich Felker2014-05-241-0/+18
| | | | | | | | | | open is handled specially because it is used from so many places, in so many variants (2 or 3 arguments, setting errno or not, and cancellable or not). trying to do it as a function would not only increase bloat, but would also risk subtle breakage. this is the first step towards supporting "new" archs where linux lacks "old" syscalls.
* make socketcall types common as they are same for all architecturesTimo Teräs2014-04-171-0/+23
|
* add working vdso clock_gettime support, including static linkingRich Felker2014-04-161-0/+91
| | | | | | | | | | | | | | | | the vdso symbol lookup code is based on the original 2011 patch by Nicholas J. Kain, with some streamlining, pointer arithmetic fixes, and one symbol version matching fix. on the consumer side (clock_gettime), per-arch macros for the particular symbol name and version to lookup are added in syscall_arch.h, and no vdso code is pulled in on archs which do not define these macros. at this time, vdso is enabled only on x86_64. the vdso support at the dynamic linker level is no longer useful to libc, but is left in place for the sake of debuggers (which may need the vdso in the link map to find its functions) and possibly use with dlsym.
* use hidden visibility rather than protected for syscall internalsRich Felker2014-04-121-1/+1
| | | | | | | | | | | | | | | the use of visibility at all is purely an optimization to avoid the need for the caller to load the GOT register or similar to prepare for a call via the PLT. there is no reason for these symbols to be externally visible, so hidden works just as well as protected, and using protected visibility is undesirable due to toolchain bugs and the lack of testing it receives. in particular, GCC's microblaze target is known to generate symbolic relocations in the GOT for functions with protected visibility. this in turn results in a dynamic linker which crashes under any nontrivial usage that requires making a syscall before symbolic relocations are processed.
* always initialize thread pointer at program startRich Felker2014-03-241-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | this is the first step in an overhaul aimed at greatly simplifying and optimizing everything dealing with thread-local state. previously, the thread pointer was initialized lazily on first access, or at program startup if stack protector was in use, or at certain random places where inconsistent state could be reached if it were not initialized early. while believed to be fully correct, the logic was fragile and non-obvious. in the first phase of the thread pointer overhaul, support is retained (and in some cases improved) for systems/situation where loading the thread pointer fails, e.g. old kernels. some notes on specific changes: - the confusing use of libc.main_thread as an indicator that the thread pointer is initialized is eliminated in favor of an explicit has_thread_pointer predicate. - sigaction no longer needs to ensure that the thread pointer is initialized before installing a signal handler (this was needed to prevent a situation where the signal handler caused the thread pointer to be initialized and the subsequent sigreturn cleared it again) but it still needs to ensure that implementation-internal thread-related signals are not blocked. - pthread tsd initialization for the main thread is deferred in a new manner to minimize bloat in the static-linked __init_tp code. - pthread_setcancelstate no longer needs special handling for the situation before the thread pointer is initialized. it simply fails on systems that cannot support a thread pointer, which are non-conforming anyway. - pthread_cleanup_push/pop now check for missing thread pointer and nop themselves out in this case, so stdio no longer needs to avoid the cancellable path when the thread pointer is not available. a number of cases remain where certain interfaces may crash if the system does not support a thread pointer. at this point, these should be limited to pthread interfaces, and the number of such cases should be fewer than before.
* include header that declares __syscall_ret where it's definedRich Felker2014-03-231-0/+1
| | | | | | | | | | | | in general, we aim to always include the header that's declaring a function before defining it so that the compiler can check that prototypes match. additionally, the internal syscall.h declares __syscall_ret with a visibility attribute to improve code generation for shared libc (to prevent gratuitous GOT-register loads). this declaration should be visible at the point where __syscall_ret is defined, too, or the inconsistency could theoretically lead to problems at link-time.
* rename superh port to "sh" for consistencyRich Felker2014-02-271-0/+0
| | | | | | | | | linux, gcc, etc. all use "sh" as the name for the superh arch. there was already some inconsistency internally in musl: the dynamic linker was searching for "ld-musl-sh.path" as its path file despite its own name being "ld-musl-superh.so.1". there was some sentiment in both directions as to how to resolve the inconsistency, but overall "sh" was favored.
* superh portBobby Bingham2014-02-231-0/+22
|
* mostly-cosmetic fixups to x32 port mergeRich Felker2014-02-231-5/+2
|
* import vanilla x86_64 code as x32rofl0r2014-02-231-0/+12
|
* internal/syscall.h: add syscall_arg_t macrorofl0r2014-02-221-6/+11
| | | | | | | some 32-on-64 archs require that the actual syscall args be long long. in that case syscall_arch.h can define syscall_arg_t to whatever it needs and syscall.h picks it up. all other archs just use long as usual.
* internal/syscall.h: use a macro for the syscall args castsrofl0r2014-02-221-13/+17
| | | | | | | this allows syscall_arch.h to define the macro __scc if special casting is needed, as is the case for x32, where the actual syscall arguments are 64bit, but, in case of pointers, would get sign-extended and thus become invalid.
* fix ftello result for append streams with unflushed outputRich Felker2014-02-071-0/+1
| | | | | | | | | | | | | | | | | | | | | | when there is unflushed output, ftello (and ftell) compute the logical stream position as the underlying file descriptor's offset plus an adjustment for the amount of buffered data. however, this can give the wrong result for append-mode streams where the unflushed writes should adjust the logical position to be at the end of the file, as if a seek to end-of-file takes place before the write. the solution turns out to be a simple trick: when ftello (indirectly) calls lseek to determine the current file offset, use SEEK_END instead of SEEK_CUR if the stream is append-mode and there's unwritten buffered data. the ISO C rules regarding switching between reading and writing for a stream opened in an update mode, along with the POSIX rules regarding switching "active handles", conveniently leave undefined the hypothetical usage cases where this fix might lead to observably incorrect offsets. the bug being fixed was discovered via the test case for glibc issue