Getaddrinfo() on glibc calls getenv(), oh boy

Re:Getaddrinfo() on glibc calls getenv(), oh boy by o11c on Tuesday October 17, 2023 @12:26AM (#37910616)

Just because it is documented as thread safe doesn't mean it actually is. They might have just not understood the problem (see e.g. the various indirect links to "please mandate a thread-local `getenv`").

`setenv` is a nasty beast, especially since the raw `environ` variable is also exposed (and is in fact the only way to enumerate the environment).

[ Parent | on HN ]

Re:Getaddrinfo() on glibc calls getenv(), oh boy by tjfontaine on Tuesday October 17, 2023 @12:45AM (#37910731)

In my experience, because it is documented that’s the behavior I would expect.

That being said, I went to look[0] and it turns out it wasn’t a lie. [0]https://github.com/illumos/illumos-gate/blob/master/usr/src/...

[ Parent | on HN ]

Re:Getaddrinfo() on glibc calls getenv(), oh boy by hddqsb on Tuesday October 17, 2023 @05:36AM (#37912534)

For the curious: They make getenv() thread-safe by intentionally leaking the old environment, which they argue is acceptable because the memory leak is bounded to 3x the space actually needed.

The getenv/setenv/putenv/environ API looks terrible on closer inspection -- it does not appear possible for an implementation to be safe, leak-free, and efficient.

[ Parent | on HN ]

Re:Getaddrinfo() on glibc calls getenv(), oh boy by o11c on Tuesday October 17, 2023 @11:35AM (#37916786)

Just because they use locks doesn't mean it's automatically actually thread-safe.

The comment about "this is safe for people walking `environ`" is definitely a lie, for example, though the bug might be hidden on some common architectures with popular compilers in their default configuration.

[ Parent | on HN ]