Brian Ford wrote:
This Cygwin bug:
http://www.cygwin.com/ml/cygwin/2004-05/msg00765.html
appears to be caused by these changes:
2003-08-22 Jeff Johnston <jjohnstn at redhat dot com>
* libc/stdio/vasprintf.c: Ditto. Also call _vfprintf_r directly.
* libc/stdio/vsnprintf.c: Ditto.
* libc/stdio/vsprintf.c: Ditto.
* libc/stdio/snprintf.c: Call _vfprintf_r directly.
* libc/stdio/sprintf.c: Ditto.
* libc/stdio/vprintf.c: Ditto. Also add _REENT_ONLY check.
Calling _vfprintf_r directly avoids the f[lock|unlock]file calls that
would happen if just _vfprintf were called.
I don't understand the reasoning for this change. Could someone please
explain? Thanks.
It was a case of eliminating an extraneous call as the _r routines in
the same files call _vfprintf_r directly. It was obviously an oversight
on my part regarding the locking aspsect, however, it is equally
obvious, the locking is being performed in the wrong place. While the
old call handled the locking for the regular I/O printf functions, the
fact remains that the _r versions of _vasprintf_r, etc.. all call
_vfprintf_r directly and they are not protected. Pushing the locking
down into _vfprintf_r should fix the problems.