question about race:stream in glibc manual

Carlos O'Donell
Wed Nov 19 02:23:00 GMT 2014

On 11/18/2014 06:52 PM, Alexandre Oliva wrote:
> On Nov 18, 2014, "Carlos O'Donell" <> 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?


More information about the Libc-help mailing list