This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH 01/10] Remove _IO_MTSAFE_IO from public headers.
- From: Joseph Myers <joseph at codesourcery dot com>
- To: Zack Weinberg <zackw at panix dot com>
- Cc: <libc-alpha at sourceware dot org>, <adhemerval dot zanella at linaro dot org>, <Wilco dot Dijkstra at arm dot com>, <fweimer at redhat dot com>, <carlos at redhat dot com>, <schwab at suse dot de>
- Date: Tue, 9 May 2017 21:11:12 +0000
- Subject: Re: [PATCH 01/10] Remove _IO_MTSAFE_IO from public headers.
- Authentication-results: sourceware.org; auth=none
- References: <20170509154103.11973-1-zackw@panix.com> <20170509154103.11973-2-zackw@panix.com>
On Tue, 9 May 2017, Zack Weinberg wrote:
> _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.
OK.
--
Joseph S. Myers
joseph@codesourcery.com