[2/3] Remove _IO_MTSAFE_IO from public headers.

  _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 internal-use-only macros
whose definitions were conditional on _IO_MTSAFE_IO are moved to
include/libio.h.  The other thing it controls is 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.

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.	Move macro definitions
	conditioned on _IO_MTSAFE_IO ...
	* include/libio.h: ... here.

	* sysdeps/generic/stdio-lock.h, sysdeps/nptl/stdio-lock.h:
	Define _IO_lock_t_defined after defining _IO_lock_t.
---
 include/libio.h              | 31 +++++++++++++++++++++----------
 libio/libio.h                | 22 +++-------------------
 sysdeps/generic/stdio-lock.h |  1 +
 sysdeps/nptl/stdio-lock.h    |  1 +
 4 files changed, 26 insertions(+), 29 deletions(-)
  

On 03/01/2017 03:02 PM, Zack Weinberg wrote:
> 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.

I tried to rip out _IO_MTSAFE_IO before, but it turns out that it still 
has an effect:

   <https://sourceware.org/ml/libc-alpha/2016-04/msg00748.html>

Are you sure your changes are actually a no-op?

Thanks,
Florian
  

On Wed, Mar 1, 2017 at 9:09 AM, Florian Weimer <fweimer@redhat.com> wrote:
> On 03/01/2017 03:02 PM, Zack Weinberg wrote:
>> 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.
>
> I tried to rip out _IO_MTSAFE_IO before, but it turns out that it still has
> an effect:
>
>   <https://sourceware.org/ml/libc-alpha/2016-04/msg00748.html>
>
> Are you sure your changes are actually a no-op?

This limited change should indeed be a no-op.  Specifically, code
compiled as part of libc (in the presence of the wrapper headers, and
in the absence of _ISOMAC) should have _IO_MTSAFE_IO defined under
exactly the same conditions as before, and should get the same
definitions of _IO_lock_t, _IO_peekc, _IO_flockfile, _IO_funlockfile,
_IO_cleanup_region_start, and _IO_cleanup_region_end as it did before.
I can do a built-objects comparison to make sure - I was already going
to do that for the main change, so it's not much extra work.

There may well be a preexisting bug where code inside libc, but
outside the stdio implementation, doesn't do all the locking that it
ought to, but my patch should not change that.

(The subtlety that you may have missed back then is
_IO_lock_inexpensive; when this is defined (by stdio-lock.h - it
appears that all supported configurations do define it), _IO_flockfile
and _IO_funlockfile expand to inline code.)

zw