_IO_MTSAFE_IO controls whether stdio is *built* with support for
multithreading. In the distant past it might also have worked as a
feature selection macro, allowing library *users* to select
thread-safe or lock-free stdio at application build time, I haven't
done the archaeology. Nowadays, defining _IO_MTSAFE_IO while using
the installed headers, or in _ISOMAC mode, will cause libio.h to throw
syntax errors.
This patch removes _IO_MTSAFE_IO from the public headers
(specifically, from libio/libio.h). The most important thing it
controlled in there was whether libio.h defines _IO_lock_t itself or
expects stdio-lock.h to have done it, and we do still need a
inter-header communication macro for that, because stdio-lock.h can
only define _IO_lock_t as a typedef. I've invented
_IO_lock_t_defined, which is defined by both versions of stdio-lock.h.
_IO_MTSAFE_IO also controlled the definitions of a handful of macros
that _might_ count as part of the public libio.h interface. They are
now unconditionally given their non-_IO_MTSAFE_IO definition in
libio/libio.h, and include/libio.h redefines them with the
_IO_MTSAFE_IO definition. This should minimize the odds of breaking
old software that actually uses those macros.
I suspect that this entire mechanism is vestigial, and that glibc
won't build anymore if you *don't* define _IO_MTSAFE_IO, but that's
another patchset. The bulk of libio.h is internal-use-only stuff that
no longer makes sense to expose (libstdc++ gave up on making a FILE
the same object as a C++ filebuf *decades* ago) but that, too, is
another patchset.
* libio/libio.h: Condition dummy definition of _IO_lock_t on
_IO_lock_t_defined, not _IO_MTSAFE_IO. Unconditionally use the
non-_IO_MTSAFE_IO definitions for _IO_peekc, _IO_flockfile,
_IO_funlockfile, and _IO_ftrylockfile. Only define
_IO_cleanup_region_start and _IO_cleanup_region_end if not
already defined.
* include/libio.h: If _IO_MTSAFE_IO is defined, redefine
_IO_peekc, _IO_flockfile, _IO_funlockfile, and _IO_ftrylockfile
appropriately.
* sysdeps/generic/stdio-lock.h, sysdeps/nptl/stdio-lock.h:
Define _IO_lock_t_defined after defining _IO_lock_t.
It was noted in
<https://sourceware.org/ml/libc-alpha/2012-09/msg00305.html> that the
bits/*.h naming scheme should only be used for installed headers.
This patch renames bits/stdio-lock.h to plain stdio-lock.h to follow
that convention.
Tested for x86_64 (testsuite, and that installed stripped shared
libraries are unchanged by the patch).
[BZ #14912]
* bits/stdio-lock.h: Move to ...
* sysdeps/generic/stdio-lock.h: ...here.
(_BITS_STDIO_LOCK_H): Rename macro to _STDIO_LOCK_H.
* sysdeps/nptl/bits/stdio-lock.h: Move to ...
* sysdeps/nptl/stdio-lock.h: ...here.
(_BITS_STDIO_LOCK_H): Rename macro to _STDIO_LOCK_H.
* include/libio.h: Include <stdio-lock.h> instead of
<bits/stdio-lock.h>.
* sysdeps/nptl/fork.c: Likewise.
* sysdeps/pthread/flockfile.c: Likewise.
* sysdeps/pthread/ftrylockfile.c: Likewise.
* sysdeps/pthread/funlockfile.c: Likewise.
Every so often someone gets confused by the fact that the installed
<bits/stdio-lock.h> header includes the non-installed <lowlevellock.h>
header.
This inclusion is not in fact a bug, because <bits/stdio-lock.h> only
gets included by any header that users should include directly if
_IO_MTSAFE_IO is defined, and that's an internal define used when
building libio, not a feature test macro it's valid for users to
define. However, on general principles it's best to have as little as
possible in the installed headers that is inapplicable for valid uses
of the installed glibc.
This patch moves the include of <bits/stdio-lock.h> to the internal
header include/libio.h, so that even if someone defines _IO_MTSAFE_IO
it won't get included. This is intended as preparation for stopping
<bits/stdio-lock.h> and <bits/libc-lock.h> from being installed at all
(after this patch they aren't used in any installed header; formally
of course they don't need to be installed even before this patch, but
stopping them being installed before removing the #include would just
exacerbate the confusion described above), and then moving those out
of the bits/ namespace in accordance with the principle that that
namespace is only for installed headers.
The tests scanf15.c and scanf17.c avoid the internal headers; after
this patch that means they need to undefine _IO_MTSAFE_IO as well as
_LIBC so as to get a working _IO_lock_t definition for libio.h. This
brings them closer to using the headers as an installed program would,
which clearly accords with the intent of those tests.
Tested for x86_64 (testsuite, and that installed stripped shared
libraries are unchanged by the patch).
* libio/libio.h [_IO_MTSAFE_IO]: Remove include of
<bits/stdio-lock.h> and commented-out include of <comthread.h>.
* include/libio.h [!_ISOMAC && _IO_MTSAFE_IO]: Include
<bits/stdio-lock.h>.
* stdio-common/scanf15.c (_IO_MTSAFE_IO): Undefine.
* stdio-common/scanf17.c (_IO_MTSAFE_IO): Likewise.
