Re: [RFC PATCH] Deprecate _REENTRANT and _THREAD_SAFE.

["Michael Kerrisk (man-pages)" <mtk dot manpages at gmail dot com>]

Hello Zack

On 12/09/2016 07:07 PM, Zack Weinberg wrote:
> On Fri, Dec 9, 2016 at 5:32 AM, Michael Kerrisk (man-pages)
> <mtk.manpages@gmail.com> wrote:
>>
>> I should perhaps have been clearer. By "queued" I meant the changes,
>> were not yet in "master"; just in a private branch.
> 
> Oh, OK.  Sorry for the misunderstanding.
> 
>> And, by now, your patch has hit the repo, so I suppose we're good
>> for adding this documentation to nam-pages "master", right?
> 
> Yes, with two more notes ...
> 
>>>> +Historically,
>>>> +defining this macro exposed definitions of certain reentrant functions.
>>>
>>> Historically, it was necessary to define this macro in all
>>> multithreaded code.
>>> Some C libraries may still require this.
>>
>> Okay. I did a little code spelunking and found the following:
> ...
>> In other words, the window of time where _REENTRANT and _THREAD_SAFE
>> did anything much in glibc was quite short, IIUC.
> 
> This is me not being clear enough.  I didn't mean to imply that this
> was historically necessary _with glibc_, but that there did once exist
> C libraries where it was necessary.  The ones I remember were
> proprietary Unix vendor libcs from the mid-1990s.  You would get
> completely unlocked stdio without _REENTRANT.

Okay. I tweaked the wording here very slightly. See below.

> What I would like the text to indicate, is that this is not necessary
> with current glibc but it might still be necessary for portable code,
> and we don't know for sure which platforms are affected.  Maybe this
> is clear enough as is? I'm not sure.

I think the existing text probably is enough.

 
>>>> +This macro is now deprecated; since glibc 2.25,
>>>> +defining it has the same effect as defining
>>>> +.BR _POSIX_C_SOURCE
>>>> +with a value of 199606L or greater.
>>>
>>> In glibc 2.25 and later,
>>> .B _REENTRANT
>>> is deprecated.
> 
> And I've decided that glibc's not going to call these macros
> "deprecated".  creature.texi says "obsolete", NEWS says "these
> nonstandard feature selection macros are now compatibility synonyms
> for _POSIX_C_SOURCE=199506L", and there are no warnings for their use.
> Would you mind adjusting the wording so that it's consistent with
> that?

Done. 

By now, the text reads:

       _REENTRANT
               Historically, on various C libraries it was  necessary  to
               define  this  macro  in  all  multithreaded code.  (Some C
               libraries may still require this.)  In glibc,  this  macro
               also exposed definitions of certain reentrant functions.

               However,  glibc  has  been thread-safe by default for many
               years; since glibc 2.3, the only effect of defining _REEN‐
               TRANT  has  been to enable one or two of the same declara‐
               tions that are also enabled  by  defining  _POSIX_C_SOURCE
               with a value of 199606L or greater.

               _REENTRANT  is  now  obsolete.   In  glibc 2.25 and later,
               defining   _REENTRANT   is    equivalent    to    defining
               _POSIX_C_SOURCE with the value 199606L.  If a higher POSIX
               conformance level is selected by any other means (such  as
               _POSIX_C_SOURCE itself, _XOPEN_SOURCE, _DEFAULT_SOURCE, or
               _GNU_SOURCE), then defining _REENTRANT has no effect.

               This macro is automatically defined if one  compiles  with
               cc -pthread.

Seem okay?

Thanks,

Michael

-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/