atomic Xprintf

[Jeff Johnston]

Brian Ford wrote:
> On Wed, 26 May 2004, Jeff Johnston wrote:
> 
> 
>>Jeff Johnston wrote:
>>
>>>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.
>>
>>Brian,
>>
>>   Can you try out the attached patch and verify if it solves the problem?
> 
> 
> Yes, this looks good.  Please apply, and thanks.
>

Patch applied.

-- Jeff J.