This is the mail archive of the mailing list for the glibc 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]


On 04/29/2016 04:36 PM, Joseph Myers wrote:
On Fri, 29 Apr 2016, Florian Weimer wrote:

Whether applications can use these macros is somewhat debatable, but as I
said, it happens within glibc as well.  There are repeated occurrences of this

My view would be:

* libio is not a public API for applications; only stdio is (and internals
should be avoided in public headers where possible).  But ABI
compatibility with old applications using libio may still be needed.

Yes, we need the ABI compatibility. I believe some of the stdio macros need <libio.h> or something like it, too.

* _IO_* symbols may be used internally in glibc for namespace reasons
(where they are function aliases), or if there is another reason for using
internals of another part of glibc.

Makes sense.

Curiously, _IO_flockfile and _IO_funlockfile are only defined in, not in  But these implementations are slightly

They seem to be in the libc.abilist files to me....

Yes, I remembered incorrectly, I got a localplt failure during building. So there currently aren't any _IO_flockfile references in, they are either expanded inline or they are elided.

I thought about the _IO_flockfile discrepancy some more. I believe we should do the following:

(1) Replace _IO_flockfile references with a new internal function (say __flockfile_nouser). This new function will perform the _IO_USER_LOCK check.

(2) Remove the symbols currently controlled by _IO_MTSAFE_IO from the API (header file at first, almost of _IO_* needs to be made compat-only, as you pointed out, but this is a different issue).


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