This is the mail archive of the newlib@sources.redhat.com mailing list for the newlib project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: atomic Xprintf


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.



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]