atomic Xprintf
Jeff Johnston
jjohnstn@redhat.com
Wed May 26 23:10:00 GMT 2004
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.
>
> -- Jeff J.
>
>
Brian,
Can you try out the attached patch and verify if it solves the problem?
-- Jeff J.
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: vfprintf.patch
URL: <http://sourceware.org/pipermail/newlib/attachments/20040526/36245245/attachment.ksh>
More information about the Newlib
mailing list