There is no clear/obvious mention of the fact that setenv could interfere with it. It is a glibc footgun/beartrap that this re-entrancy doesn't actually mean calling it with non-shared memory in the arguments ensures no data races.
there could very well be a bug. if there's a bug, fix it.
But from what I read, it's documented as not threadsafe and this problem is happening in a threaded environment. That still could be called a bug. You find bugs, you fix them;
That's better than hyperventilating about how there is some massive problem with an operating system that you are using because all the people who came before you who knew more than you decided it was the best thing to use. The other OSes sucked more. This OS is simple enough that you can actually learn how it works, it's all laid out in front of you.
Should it do some additional things? sure. Help write the code.
A beartrap/footgun means "a bit too easy to harm yourself for comfort", not "there is a bug". I am relatively old and have been programming to this interface for a few decades, so I'm not hyperventilating about it.
My point (which made reference to the actual OS documentation) was that it takes being bit by such issues before you learn what this "Attributes" section means:
For the 1st decade of my career, I just searched for "re-entrant", "reentrant", or "MT" and went on my merry way, without realizing the importance of the other possible values of attributes table: in this case "env".
when you read the doc and realized you missed something, don't say "footgun", say "aha! I misunderstood" Then if you want, set about to make things better.
Instead of jumping to "It shouldn't work this way" consider "Hmmm, why does it work this way? Is it possible that Thompson, Kernighan and Ritchie knew more about how to make a coherent straightforward system that would last 50 years in 1970 than I know how to now?"
Or perhaps you might consider that we've learned something in the last 50 years.
It sounds to me like you're hyperventilating about other people pointing out footguns. Maybe, just maybe, people in the past were capable of making mistakes. Let's not put them on a pedestal.
In fairness, they also gave us the joys of `strcpy(src_ptr, dest_ptr)` and `scanf("%s", str_ptr)`, which with the benefit of hindsight and many buffer overflows later were a terrible idea.
Yes, I reference that table in a deeper comment. I didn't mean that it wasn't accurately documented, but rather that it's not immediately apparent. I know lots of people who were once quite experienced but still not enough to know what the attributes section is and its importance and its full meaning (myself included).
Indeed, surprising and easy to overlook was all I was trying to convey.
┌───────────────────────────┬───────────────┬────────────────────┐
│Interface │ Attribute │ Value │
├───────────────────────────┼───────────────┼────────────────────┤
│getaddrinfo() │ Thread safety │ MT-Safe env locale │
├───────────────────────────┼───────────────┼────────────────────┤
│freeaddrinfo(), │ Thread safety │ MT-Safe │
│gai_strerror() │ │ │
└───────────────────────────┴───────────────┴────────────────────┘
MT-Safe
MT-Safe or Thread-Safe functions are safe to call in the
presence of other threads. MT, in MT-Safe, stands for
Multi Thread.
Being MT-Safe does not imply a function is atomic, nor
that it uses any of the memory synchronization mechanisms
POSIX exposes to users. It is even possible that calling
MT-Safe functions in sequence does not yield an MT-Safe
combination. For example, having a thread call two MT-
Safe functions one right after the other does not
guarantee behavior equivalent to atomic execution of a
combination of both functions, since concurrent calls in
other threads may interfere in a destructive way.
Whole-program optimizations that could inline functions
across library interfaces may expose unsafe reordering,
and so performing inlining across the GNU C Library
interface is not recommended. The documented MT-Safety
status is not guaranteed under whole-program optimization.
However, functions defined in user-visible headers are
designed to be safe for inlining.
Other safety remarks
Additional keywords may be attached to functions, indicating
features that do not make a function unsafe to call, but that may
need to be taken into account in certain classes of programs:
locale Functions annotated with locale as an MT-Safety issue read
from the locale object without any form of
synchronization. Functions annotated with locale called
concurrently with locale changes may behave in ways that
do not correspond to any of the locales active during
their execution, but an unpredictable mix thereof.
We do not mark these functions as MT-Unsafe, however,
because functions that modify the locale object are marked
with const:locale and regarded as unsafe. Being unsafe,
the latter are not to be called when multiple threads are
running or asynchronous signals are enabled, and so the
locale can be considered effectively constant in these
contexts, which makes the former safe.
env Functions marked with env as an MT-Safety issue access the
environment with getenv(3) or similar, without any guards
to ensure safety in the presence of concurrent
modifications.
We do not mark these functions as MT-Unsafe, however,
because functions that modify the environment are all
marked with const:env and regarded as unsafe. Being
unsafe, the latter are not to be called when multiple
threads are running or asynchronous signals are enabled,
and so the environment can be considered effectively
constant in these contexts, which makes the former safe.
Yes, I talk about that table in a deeper comment. Note to other readers, the table itself is in getaddrinfo(3) but the explanation of the elements is in attributes(7).
There is no clear/obvious mention of the fact that setenv could interfere with it. It is a glibc footgun/beartrap that this re-entrancy doesn't actually mean calling it with non-shared memory in the arguments ensures no data races.