musl - musl - an implementation of the standard library for Linux-based systems

Age	Commit message (Collapse)	Author	Lines
2015-06-16	byte-based C locale, phase 2: stdio and iconv (multibyte callers)	Rich Felker	-5/+6
	this patch adjusts libc components which use the multibyte functions internally, and which depend on them operating in a particular encoding, to make the appropriate locale changes before calling them and restore the calling thread's locale afterwards. activating the byte-based C locale without these changes would cause regressions in stdio and iconv. in the case of iconv, the current implementation was simply using the multibyte functions as UTF-8 conversions. setting a multibyte UTF-8 locale for the duration of the iconv operation allows the code to continue working. in the case of stdio, POSIX requires that FILE streams have an encoding rule bound at the time of setting wide orientation. as long as all locales, including the C locale, used the same encoding, treating high bytes as UTF-8, there was no need to store an encoding rule as part of the stream's state. a new locale field in the FILE structure points to the locale that should be made active during fgetwc/fputwc/ungetwc on the stream. it cannot point to the locale active at the time the stream becomes oriented, because this locale could be mutable (the global locale) or could be destroyed (locale_t objects produced by newlocale) before the stream is closed. instead, a pointer to the static C or C.UTF-8 locale object added in commit commit aeeac9ca5490d7d90fe061ab72da446c01ddf746 is used. this is valid since categories other than LC_CTYPE will not affect these functions.
2014-07-01	fix incorrect return value for fwide function	Rich Felker	-1/+2
	when the orientation of the stream was already set, fwide was incorrectly returning its argument (the requested orientation) rather than the actual orientation of the stream.
2013-12-12	include cleanups: remove unused headers and add feature test macros	Szabolcs Nagy	-0/+1

2012-10-24	correct locking in stdio functions that tried to be lock-free	Rich Felker	-2/+4
	these functions must behave as if they obtain the lock via flockfile to satisfy POSIX requirements. since another thread can provably hold the lock when they are called, they must wait to obtain the lock before they can return, even if the correct return value could be obtained without locking. in the case of fclose and freopen, failure to do so could cause correct (albeit obscure) programs to crash or otherwise misbehave; in the case of feof, ferror, and fwide, failure to obtain the lock could sometimes return incorrect results. in any case, having these functions proceed and return while another thread held the lock was wrong.
2011-02-12	initial check-in, version 0.5.0v0.5.0	Rich Felker	-0/+10