question about race:stream in glibc manual

[Carlos O'Donell]

On 11/18/2014 06:52 PM, Alexandre Oliva wrote:
> On Nov 18, 2014, "Carlos O'Donell" <carlos@redhat.com> wrote:
> 
>> On 11/13/2014 07:24 PM, MaShimiao wrote:
> 
>>> According to the manual, I think if a function has an argument FILE
>>> *stream and the stream may cause data races inside the function, it
>>> should annotated with MT-Safe race:stream. Am I right?
> 
>> You are not correct. The FILE* is an opaque object.
> 
> We experimented with distinguishing opaque and non-opaque objects for
> some time, but in the end we decided not to make this distinction.  In
> the version we put in the manual, we state the user is responsible for
> synchronization WRT all objects chosen by the user, but we explicitly
> annotate functions with race:<parm> as a reminder, when opaqueness or
> custom might suggest the library would take care of it.
> 
> addmntent is indeed MT-Safe, although there's a potential for unintended
> behavior if the stream is repositioned between the seek and the write.

IMO that's a bug. The API contract for addmntent requires the structure
be written at the end of the open file fp. It should lock the stream,
seek to the end, write, and unlock.

> I said I wouldn't install the patch that fixes this if there were
> objections by Tuesday.  So now I'm gonna wait till I hear back from you
> before I check it in.  Please let me know.

I'm feeling very dense. What patch?

Cheers,
Carlos.