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

<http://refi64.com/>

  
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