musl/src/stdio/stdin.c

#include "stdio_impl.h"

static unsigned char buf[BUFSIZ+UNGET];
static FILE f = {
	.buf = buf+UNGET,
	.buf_size = sizeof buf-UNGET,
	.fd = 0,
	.flags = F_PERM | F_NOWR,
	.read = __stdio_read,
	.seek = __stdio_seek,
	.close = __stdio_close,
	.lock = -1,
};
FILE *const stdin = &f;
FILE *volatile __stdin_used = &f;
initial check-in, version 0.5.0 2011-02-12 00:22:29 -05:00			`#include "stdio_impl.h"`

			`static unsigned char buf[BUFSIZ+UNGET];`
			`static FILE f = {`
			`.buf = buf+UNGET,`
			`.buf_size = sizeof buf-UNGET,`
			`.fd = 0,`
			`.flags = F_PERM \| F_NOWR,`
			`.read = __stdio_read,`
			`.seek = __stdio_seek,`
			`.close = __stdio_close,`
add proper fuxed-based locking for stdio previously, stdio used spinlocks, which would be unacceptable if we ever add support for thread priorities, and which yielded pathologically bad performance if an application attempted to use flockfile on a key file as a major/primary locking mechanism. i had held off on making this change for fear that it would hurt performance in the non-threaded case, but actually support for recursive locking had already inflicted that cost. by having the internal locking functions store a flag indicating whether they need to perform unlocking, rather than using the actual recursive lock counter, i was able to combine the conditionals at unlock time, eliminating any additional cost, and also avoid a nasty corner case where a huge number of calls to ftrylockfile could cause deadlock later at the point of internal locking. this commit also fixes some issues with usage of pthread_self conflicting with __attribute__((const)) which resulted in crashes with some compiler versions/optimizations, mainly in flockfile prior to pthread_create. 2011-07-30 08:02:14 -04:00			`.lock = -1,`
initial check-in, version 0.5.0 2011-02-12 00:22:29 -05:00			`};`
			`FILE *const stdin = &f;`
work around constant folding bug 61144 in gcc 4.9.0 and 4.9.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-16 21:32:06 -04:00			`FILE *volatile __stdin_used = &f;`