This is the mail archive of the
mailing list for the glibc project.
- From: Florian Weimer <fweimer at redhat dot com>
- To: Joseph Myers <joseph at codesourcery dot com>
- Cc: GNU C Library <libc-alpha at sourceware dot org>
- Date: Mon, 2 May 2016 10:32:44 +0200
- Subject: Re: _IO_MTSAFE_IO
- Authentication-results: sourceware.org; auth=none
- References: <572316A7 dot 2060209 at redhat dot com> <alpine dot DEB dot 2 dot 20 dot 1604291430410 dot 10400 at digraph dot polyomino dot org dot uk>
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.
Curiously, _IO_flockfile and _IO_funlockfile are only defined in
libpthread.so, not in libc.so. 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 libc.so,
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
(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).