musl/src/stdio/fwide.c

#include <wchar.h>
#include "stdio_impl.h"

#define SH (8*sizeof(int)-1)
#define NORMALIZE(x) ((x)>>SH | -((-(x))>>SH))

int fwide(FILE *f, int mode)
{
	FLOCK(f);
	if (!f->mode) f->mode = NORMALIZE(mode);
	mode = f->mode;
	FUNLOCK(f);
	return mode;
}
include cleanups: remove unused headers and add feature test macros 2013-12-12 05:09:18 +00:00			`#include <wchar.h>`
initial check-in, version 0.5.0 2011-02-12 00:22:29 -05:00			`#include "stdio_impl.h"`

			`#define SH (8*sizeof(int)-1)`
			`#define NORMALIZE(x) ((x)>>SH \| -((-(x))>>SH))`

			`int fwide(FILE *f, int mode)`
			`{`
correct locking in stdio functions that tried to be lock-free 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. 2012-10-24 23:16:41 -04:00			`FLOCK(f);`
fix incorrect return value for fwide function 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. 2014-07-01 18:49:54 -04:00			`if (!f->mode) f->mode = NORMALIZE(mode);`
			`mode = f->mode;`
correct locking in stdio functions that tried to be lock-free 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. 2012-10-24 23:16:41 -04:00			`FUNLOCK(f);`
			`return mode;`
initial check-in, version 0.5.0 2011-02-12 00:22:29 -05:00			`}`