When getenv can alter content of previously returned pointer when using glibc?

Question

C standard says that:

The getenv function returns a pointer to a string associated with the matched list member. The string pointed to shall not be modified by the program, but may be overwritten by a subsequent call to the getenv function.

As I understand, getenv implementation in glibc(I used ver. 2.17) returns element from global variable called char **environ. Every subsequent call to the getenv function still returns one of the elements from this array(or null when such env variable doesn't exist) without altering any of previously returned values.

Is any alternation of content of previously returned pointer by getenv function possible by subsequent call to the getenv function when using glibc? If yes, when?

`getenv("PATH")` returns the pointer to the value after the `=` sign in `PATH=/usr/bin`, but the pointer in the `environ` array points to the `P` of `PATH`. Extreme pedantry, but just making sure you're aware. Just because the Unix-based systems don't overwrite internal storage doesn't mean that other implementations might not. On a system designed to read environment variables on demand from a file-based central storage area (a repository), new calls to `getenv()` might well overwrite the result from a prior call. That is permitted by the C standard; it is not mandated by the C standard. — Jonathan Leffler, Nov 02 '13 at 20:55

score 2 · Answer 1 · answered Nov 02 '13 at 19:58

If I correctly understood, getenv can theoretically be implemented by copying the string into it's internal static buffer and returning a pointer to it instead of giving a pointer to environ member. If so, the string will be changed by each getenv call.

score 2 · Accepted Answer · answered Nov 02 '13 at 20:02

2

This is really just a bug in the standards. Even C11 keeps language that allows the buffer to be overwritten, but at the same time, it does not permit data races with other calls to getenv, only with (implementation-defined) functions which modify the environment, so permitting this overwriting to take place seems contradictory.

On all real-world implementations, including glibc, getenv returns the pointer to the copy of the string in the internal representation of the environment, and will never be invalidated except possibly if you call functions which modify the environment.

answered Nov 02 '13 at 20:02

R.. GitHub STOP HELPING ICE

208,859
35
376
711

Not a bug; it allows implementers a flexibility that Unix systems do not require (but other systems might require). – Jonathan Leffler Nov 02 '13 at 20:58
My claim that it's a bug is based on the conflicting language in C11 and the fact that taking this allowance precludes any reasonable use of the environment with threads (which C11 and POSIX both offer). – R.. GitHub STOP HELPING ICE Nov 03 '13 at 14:29
The allowance doesn't preclude use of the environment with threads. A per-thread buffer can be used. POSIX adds a note that the buffer may be invalidated by termination of the calling thread, which appears to be weakening of the C11 requirements, but I suspect this is a defect in the C standard rather than in POSIX. – davmac Jul 10 '22 at 01:01

technosaurus · Answer 3 · 2013-11-02T23:06:52.360

Perhaps a demo will help:

char *getenv(const char *var){
    int i=0, len=strlen(var);
    if (!environ||!*var||strchr(var,'='))
        return NULL;
    while ( environ[i] && (environ[i][len] != '=' || strncmp(var,environ[i],len)) )
        i++;
    return (environ[i])? environ[i]+len+1 : NULL;
}

Each call will get an appropriate pointer to the global extern 2d array environ, which is why the program should not modify it, because it would actually modify the environ variable; however a subsequent call to getenv may get the value in a different position (if setenv or putenv has changed it)

Notice that you are getting a pointer to the middle of a string. Think of what would happen if you changed it. Then at any given point the **environ may change so that address is pointing to some other variable (or junk) ... if you need to use that string long term, you should copy it just to be safe (especially in threaded environments)

What it is saying is that you can do mycharptr=getenv("myvar"); as often as you wish, that is safe, but don't do mycharptr=getenv("myvar");mycharptr[0]='\0'; ... mycharptr=getenv("myvar");... or you may get unexpected results.

When getenv can alter content of previously returned pointer when using glibc?

3 Answers3