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

Re:Getaddrinfo() on glibc calls getenv(), oh boy by Sprocklem on Tuesday October 17, 2023 @05:00PM (#37921496)

Of course, *_r is a better option, but the existing API is used so pervasively that it needs to be made thread-safe to actually avoid thread-unsafe code in, e.g, libraries.

[ Parent | on HN ]

Re:Getaddrinfo() on glibc calls getenv(), oh boy by lokar on Tuesday October 17, 2023 @11:44PM (#37924638)

I don’t see how you can make:

- return a pointer - the library owns the allocation - the state is global and mutable

Thread safe

[ Parent | on HN ]

Re:Getaddrinfo() on glibc calls getenv(), oh boy by Sprocklem on Wednesday October 18, 2023 @07:54AM (#37927389)

A number of libc functions return a pointer to an internal thread-local buffer, which is invalidated on subsequent calls. If the function copies the environment variable's value to such a buffer while holding the mutex controlling access to the global state, then the returned value is guaranteed to remain unaffected by other threads.

There are, however, other problems (discussed elsewhere in this thread) that complicate such an API in the context of getenv().

[ Parent | on HN ]

Re:Getaddrinfo() on glibc calls getenv(), oh boy by lokar on Wednesday October 18, 2023 @11:16AM (#37929884)

Requiring you to hold a mutex to safely call the function is an API change

[ Parent | on HN ]

Re:Getaddrinfo() on glibc calls getenv(), oh boy by Sprocklem on Wednesday October 18, 2023 @03:47PM (#37933817)

I was not suggesting the caller hold a mutex, but rather getenv(), which eould be transparent to the caller.

[ Parent | on HN ]

Re:Getaddrinfo() on glibc calls getenv(), oh boy by lokar on Thursday October 19, 2023 @08:37PM (#37950759)

Don’t you need C++11?

[ Parent | on HN ]