This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [RFC PATCH] Deprecate _REENTRANT and _THREAD_SAFE.
- From: "Michael Kerrisk (man-pages)" <mtk dot manpages at gmail dot com>
- To: Zack Weinberg <zackw at panix dot com>
- Cc: mtk dot manpages at gmail dot com, libc-alpha <libc-alpha at sourceware dot org>
- Date: Fri, 9 Dec 2016 11:32:49 +0100
- Subject: Re: [RFC PATCH] Deprecate _REENTRANT and _THREAD_SAFE.
- Authentication-results: sourceware.org; auth=none
- References: <20161206152204.2064-1-zackw@panix.com> <CALxWeYozGxUHi8wPhHd4fgx=DPtg4UG0UC2Znq7HfOd2JJxBmA@mail.gmail.com> <CAKCAbMh0e6L+bT80v4E=q9Q537GxBk3ppWMhibnsrmb6sfPCbA@mail.gmail.com>
Hello Zack,
On 12/08/2016 03:01 PM, Zack Weinberg wrote:
> On Thu, Dec 8, 2016 at 4:01 AM, Michael Kerrisk <mtk.manpages@gmail.com> wrote:
>>
>> On the assumption that this patch will be merged in some form, I've
>> queued the following change to feature_test_macros(7):
>
> I appreciate the vote of confidence, but please don't actually put
> that into the manpages until the patch does get merged.
I should perhaps have been clearer. By "queued" I meant the changes,
were not yet in "master"; just in a private branch.
And, by now, your patch has hit the repo, so I suppose we're good
for adding this documentation to nam-pages "master", right?
> Also, some
> corrections/clarifications:
There's nothing like queuing a bad patch to get someone to write a
good patch
>> +Historically,
>> +defining this macro exposed definitions of certain reentrant functions.
>
> Historically, it was necessary to define this macro in all
> multithreaded code.
Okay. I did a little code spelunking and found the following:
1. In glibc 1.09 (tagged 1995-03-02 in the git history), __USE_REENTRANT,
_THREAD_SAFE, and _REENTRANT do not appear.
2. In glibc-1.93 (tagged 1996-08-29 in the git history), __USE_REENTRANT
governs the exposure of some "_r()" functions from about a dozen header
files. However, it is defined in <features.h> via
#if defined (__USE_GNU) || defined (__USE_MISC)
#define __USE_REENTRANT 1
#endif
_REENTRANT and _THREAD_SAFE solely govern declarations in <stdio.h>,
where they expose declarations of a few "unlocked" stdio functions
and use #define to redirect a few stdio function names
to "locked" versions.
3. THREAD_SAFE and _REENTRANT first appear in the git logs
1996-05-09.
4. About 9 months later, glibc 2.0.1 arrives on 1997-02-04
(timestamp and tarball taken from https://ftp.gnu.org/gnu/libc/,
since there is no tag in the git history; casual inspection of
the logs suggests the glibc 2.0 release was about a week earlier.
By now we have the following in <features.h>:
#if defined _REENTRANT || defined _THREAD_SAFE
#define __USE_REENTRANT 1
#endif
And _THREAD_SAFE, and _REENTRANT do not appear appear in other
headers. However, by now, __USE_REENTRANT governs only the
declarations of tmpnam_r() and getlogin_r()
In other words, the window of time where _REENTRANT and _THREAD_SAFE
did anything much in glibc was quite short, IIUC.
> Some C libraries may still require this.
>
>> +However, already for many years this macro has had few effects,
>> +and since glibc 2.3, no effects that were not also achieved by defining
>> +.BR _POSIX_C_SOURCE
>> +with a value of 199606L or greater.
>
> However, glibc has been thread-safe by default for many years; since
> glibc 2.3, the only effect of
> .B _REENTRANT
> has been to enable some of the same declarations enabled by defining
> .B _POSIX_C_SOURCE
> with a value of 199606L or later.
>
>> +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. Defining it is equivalent to defining
> .B _POSIX_C_SOURCE
> with the value 199606L. If a higher POSIX conformance level is
> selected by any other means (such as
> .B _POSIX_C_SOURCE
> itself,
> .BR _XOPEN_SOURCE ,
> .BR _DEFAULT_SOURCE ,
> or
> .BR _GNU_SOURCE ),
> then
> .B _REENTRANT
> has no effect.
>
> (Perhaps there is a tighter way to write the markup? Feel free to tweak.)
I'm fine with the markup as you gave it. I've taken the changes
pretty much as you've given them here.
Cheers,
Michael
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/