correct locking in stdio functions that tried to be lock-free
authorRich Felker <dalias@aerifal.cx>
Thu, 25 Oct 2012 03:16:41 +0000 (23:16 -0400)
committerRich Felker <dalias@aerifal.cx>
Thu, 25 Oct 2012 03:16:41 +0000 (23:16 -0400)
commitc8cb6bcdf009e94c12c6e256b8e24a9bc5fdaf05
tree28d9441f99c5449267c987cb46b6610dc244a991
parent892cafff665b44d238e3b664f61ca38dd965cba6
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.
src/stdio/fclose.c
src/stdio/feof.c
src/stdio/ferror.c
src/stdio/fileno.c
src/stdio/freopen.c
src/stdio/fwide.c