Question about the use of _newlib_flockfile_* in newlib

[Bin.Cheng]

Hi Jeff,
There is typo in your checkin for puts.c

  _newlib_flockfile_start (_stdout_r (ptr));
  ORIENT (_stdout_r (ptr), -1);
  result = (__sfvwrite_r (ptr, _stdout_r (ptr), &uio) ? EOF : '\n');
  _newlib_flockfile_start (_stdout_r (ptr));

Thanks.


On Tue, Dec 18, 2012 at 3:55 AM, Jeff Johnston <jjohnstn@redhat.com> wrote:
> On 12/17/2012 05:53 AM, Corinna Vinschen wrote:
>>
>> On Dec 17 10:06, Bin.Cheng wrote:
>>>
>>> Hi,
>>> I have two questions on _newlib_flockfile_*.
>>> 1.
>>> _fputc_r calls _putc_r to do the job, but both of them calls
>>> _newlib_flockfile_*. Is it OK? Why if it is.
>>
>>
>> I'm not quite sure, but I think the reason is that putc and, in analogy,
>> _putc_r might be defined as macro.  Newlib doesn't do that by default
>> for _putc_r, but target-specific code could.
>>
>>> 2. In most functions, the macro ORIENT() is guarded by
>>> _newlib_flockfile_*, but it is not in _puts_r. Anything special or
>>> just missed something?
>>
>>
>> I had a look into the CVS annotation and it seems that this is not about
>> ORIENT, but about the fact that the __sfvwrite_r call in _puts_r was
>> never guarded by a flockfile/funlockfile (the predecessor of
>> _newlib_flockfile_start/_newlib_flockfile_end).
>>
>> I don't know why, though.  Jeff?
>>
>
> Don't know why this is the case.  Perhaps puts used to call fputs previously
> which has the lock protection so the locks were never needed.  I can't see
> any reason not to add them in the present case.
>
> -- Jeff J.
>>
>>
>> Corinna
>>
>



-- 
Best Regards.