4 ms·

Most people would expect getaddrinfo to be re-entrant, and in the Linux man 3 page it is: https://www.man7.org/linux/man-pages/man3/getaddrinfo.3.html https://w

Most people would expect getaddrinfo to be re-entrant, and in the Linux man 3 page it is: https://www.man7.org/linux/man-pages/man3/getaddrinfo.3.html https://www.man7.org/linux/man-pages/man3/getaddrinfo.3.html 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.

fsckboy 3y ago
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.
- dundarious 3y ago
  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: > │Interface │ Attribute │ Value │ > │getaddrinfo() │ Thread safety │ MT-Safe env locale │ 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". It's worth highlighting!
  - fsckboy 3y ago
    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?"
    - burntsushi 3y ago
      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.
    - rb12345 3y ago
      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.
formerly_proven 3y ago
┌───────────────────────────┬───────────────┬────────────────────┐ │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.
gpderetta 3y ago
In the attribute table, thread safety is clearly marked as "Thread-Safe, env", with a link just below explaining the meaning of the attributes. As many things, the behaviour is surprising and can be overlooked. But undocumented is not.
- dundarious 3y ago
  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.

fsckboy 3y ago

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.

dundarious 3y ago
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: > │Interface │ Attribute │ Value │ > │getaddrinfo() │ Thread safety │ MT-Safe env locale │ 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". It's worth highlighting!
- fsckboy 3y ago
  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?"
  - burntsushi 3y ago
    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.
  - rb12345 3y ago
    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.

formerly_proven 3y ago

┌───────────────────────────┬───────────────┬────────────────────┐ │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.

gpderetta 3y ago

In the attribute table, thread safety is clearly marked as "Thread-Safe, env", with a link just below explaining the meaning of the attributes. As many things, the behaviour is surprising and can be overlooked. But undocumented is not.

dundarious 3y ago
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.