Just a wild guess, but I think it could be because getenv just returns a null-terminated string with no indication of its length. If C code were to do pretty much anything on the environment variable in question, it would always be truncated. e.g. with VAR=ABC\0DEF, the C string processing functions would assume it ended after ABC.

As a side note, Linux does nothing and simply returns it as-is. I wonder why the Posix guys haven't added a getenv_n(var, &length) function yet...

--
Ryan (ライアン)
Yoko Shimomura > ryo (supercell/EGOIST) > Hiroyuki Sawano >> everyone else

On Jan 18 2017, at 10:47 am, Giacomo Tesio <giacomo@tesio.it> wrote:

Hi, last night I noticed this strange post processing in 4th edition's
getenv: https://github.com/brho/plan9/blob/master/sys/src/libc/9sys/getenv.c#L34-L41

        seek(f, 0, 0);
        r = read(f, ans, s);
        if(r >= 0) {
            ep = ans + s - 1;
            for(p = ans; p < ep; p++)
                if(*p == '\0')
                    *p = ' ';
            ans[s] = '\0';
        }

Anybody know why this replacement is done?
It does not seem a good fix to read/write or read/truncate races, but
I can't find a better explanation.


Giacomo