atomic Xprintf
Jeff Johnston
jjohnstn@redhat.com
Wed May 26 22:47:00 GMT 2004
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.
-- Jeff J.
More information about the Newlib
mailing list