Hacker News Reader

Doesn’t the essay contradict itself?

It states that glibc “never free[s] environment variables], but then goes on to state

> [in glibc] if a thread calling setenv() needs to resize the array of pointers, it copies the values to a new array and frees the previous one

Since envvars cause crash under glibc, I assume the initial assertion is incorrect.

View on HN

There are two level of pointers: the environment block points to an array of pointers to C strings, this higher-level pointer can be updated and the previous one freed, which is a problem when it is being iterated on (which getenv does). The C strings themselves aren't freed by glibc, though some applications do modify them in place.

OIC, so because glibc doesn't hold the setenv lock during lookup a concurrent getenv can break, but once getenv has found an entry that entry is guaranteed to be valid (unless the application plays silly bugger) because setenv will not free the individual entries.

Reply on news.ycombinator.com