This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH 01/10] Remove _IO_MTSAFE_IO from public headers.


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]