summaryrefslogtreecommitdiff
path: root/src/stdio/__stdio_exit.c
AgeCommit message (Collapse)AuthorFilesLines
2015-06-16refactor stdio open file list handling, move it out of global libc structRich Felker1-2/+1
functions which open in-memory FILE stream variants all shared a tail with __fdopen, adding the FILE structure to stdio's open file list. replacing this common tail with a function call reduces code size and duplication of logic. the list is also partially encapsulated now. function signatures were chosen to facilitate tail call optimization and reduce the need for additional accessor functions. with these changes, static linked programs that do not use stdio no longer have an open file list at all.
2014-07-16work around constant folding bug 61144 in gcc 4.9.0 and 4.9.1Rich Felker1-1/+1
previously we detected this bug in configure and issued advice for a workaround, but this turned out not to work. since then gcc 4.9.0 has appeared in several distributions, and now 4.9.1 has been released without a fix despite this being a wrong code generation bug which is supposed to be a release-blocker, per gcc policy. since the scope of the bug seems to affect only data objects (rather than functions) whose definitions are overridable, and there are only a very small number of these in musl, I am just changing them from const to volatile for the time being. simply removing the const would be sufficient to make gcc 4.9.1 work (the non-const case was inadvertently fixed as part of another change in gcc), and this would also be sufficient with 4.9.0 if we forced -O0 on the affected files or on the whole build. however it's cleaner to just remove all the broken compiler detection and use volatile, which will ensure that they are never constant-folded. the quality of a non-broken compiler's output should not be affected except for the fact that these objects are no longer const and thus possibly add a few bytes to data/bss. this change can be reconsidered and possibly reverted at some point in the future when the broken gcc versions are no longer relevant.
2014-07-16simplify __stdio_exit static linking logicRich Felker1-0/+2
the purpose of this logic is to avoid linking __stdio_exit unless any stdio reads (which might require repositioning the file offset at exit time) or writes (which might require flushing at exit time) could have been performed. previously, exit called two wrapper functions for __stdio_exit named __flush_on_exit and __seek_on_exit. both of these functions actually performed both tasks (seek and flushing) by calling the underlying __stdio_exit. in order to avoid doing this twice, an overridable data object __towrite_used was used to cause __seek_on_exit to act as a nop when __towrite was linked. now, exit only makes one call, directly to __stdio_exit. this is satisfiable by a weak dummy definition in exit.c, but the real definition is pulled in by either __toread.c or __towrite.c through their referencing a symbol which is defined only in __stdio_exit.c.
2012-11-01fix more unused variable warningsRich Felker1-1/+1
some of these were coming from stdio functions locking files without unlocking them. I believe it's useful for this to throw a warning, so I added a new macro that's self-documenting that the file will never be unlocked to avoid the warning in the few places where it's wrong.
2012-06-19stdio: handle file position correctly at program exitRich Felker1-0/+23
for seekable files, posix imposed requirements on the offset of the underlying open file description after a stream is closed. this was correctly handled (as a side effect of the unconditional fflush call) when streams were explicitly closed by fclose, but was not handled correctly at program exit time, where fflush(0) was being used. the weak symbol hackery is to pull in __stdio_exit if either of __toread or __towrite is used, but avoid calling it twice so we don't have to keep extra state. the new __stdio_exit is a streamlined fflush variant that avoids performing any unnecessary operations and which never unlocks the files or open file list, so we can be sure no other threads write new data to a stream's buffer after it's already flushed.