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 <[email protected]> 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
