[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
_REENTRANT and _THREAD_SAFE
From: |
Bruno Haible |
Subject: |
_REENTRANT and _THREAD_SAFE |
Date: |
Mon, 27 Feb 2017 23:34:52 +0100 |
User-agent: |
KMail/5.1.3 (Linux/4.4.0-64-generic; KDE/5.18.0; x86_64; ; ) |
Hi all,
gnulib uses the _REENTRANT and _THREAD_SAFE macros in a couple of modules:
m4/threadlib.m4
m4/readutmp.m4
Does anyone know in detail what this glibc change [1] means in detail?
* The nonstandard feature selection macros _REENTRANT and _THREAD_SAFE
are now treated as compatibility synonyms for _POSIX_C_SOURCE=199506L.
Since the GNU C Library defaults to a much newer revision of POSIX,
this will only affect programs that specifically request an old
conformance mode. For instance, a program compiled with -std=c89
-D_REENTRANT will see a change in the visible declarations, but a
program compiled with just -D_REENTRANT, or -std=c99
-D_POSIX_C_SOURCE=200809L -D_REENTRANT, will not.
Some C libraries once required _REENTRANT and/or _THREAD_SAFE to be
defined by all multithreaded code, but glibc has not required this for
many years.
Does it mean that _REENTRANT and _THREAD_SAFE now prevent some symbols
from being declared?
My perspective is not "what has changed between glibc 2.24 and 2.25" but
"In glibc 2.25, what is the effect of defining _REENTRANT or _THREAD_SAFE?".
May it cause harm to add _REENTRANT or _THREAD_SAFE to the CPPFLAGS?
Bruno
[1] https://lists.gnu.org/archive/html/info-gnu/2017-02/msg00002.html
- _REENTRANT and _THREAD_SAFE,
Bruno Haible <=