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