Re: [PATCH 2/3] Remove _IO_MTSAFE_IO from public headers.

[Zack Weinberg <zackw at panix dot com>]

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