bug-gnulib
[Top][All Lists]
Advanced

[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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]