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

[Adhemerval Zanella <adhemerval.zanella@linaro.org>]

On 06/04/2017 19:06, Florian Weimer wrote:
> On 04/06/2017 11:29 PM, Adhemerval Zanella wrote:
>>
>>
>> On 06/04/2017 17:41, Zack Weinberg wrote:
>>> On Thu, Apr 6, 2017 at 4:29 PM, Adhemerval Zanella
>>> <adhemerval.zanella@linaro.org> wrote:
>>>> On 22/03/2017 09:55, 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.
>>>>
>>>> What prevent us to just get rid of _IO_MTSAFE_IO and just build/assume
>>>> stdio with multithread support?
>>>
>>> I think that's a desirable goal, but I don't want to do that in this
>>> patchset because I suspect it will be messy *inside* libc.  And I'd
>>> start by getting it out of the public headers, anyway.
>>
>> Why do you think so? The make fragment sysdeps/pthread/Makeconfig already
>> sets libc-reentrant regardless, so _IO_MTSAFE_IO is already being defined
>> in all objects that might use it (and I suspect it has been this way for
>> some time already).
> 
> There is some oddity going on with regards to the libio locking macros. A previous discussion:
> 
>   <https://sourceware.org/ml/libc-alpha/2016-04/msg00748.html>
>   (spans into next month)
> 
> Obviously, we need to clean this up, but we need to be careful to preserve the locking behavior expected by applications.
> 
> Thanks,
> Florian

Right, removing _IO_MTSAFE_IO seems no be not a trivial issue. I think
we can push it in the future then.