Yes that would be a plausible explanation but actually rc does not use
getenv: it reads /env/ files directly.
I've tried to remove the loop and I can't see any issue.
Giacomo
2017-01-18 21:13 GMT+01:00 Charles Forsyth :
> Yes, it's the lists. Nothing will cope with \0 in a C string, so it's a
Yes, it's the lists. Nothing will cope with \0 in a C string, so it's a
good choice as list of string element separator.
On 18 January 2017 at 19:21, Fran. J Ballesteros wrote:
> rc lists?
>
> > El 18 ene 2017, a las 17:45, Giacomo Tesio escribió:
> >
> > Hi, last night I noticed this strange p
rc lists?
> El 18 ene 2017, a las 17:45, Giacomo Tesio escribió:
>
> 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);
>
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 functio
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++)
Oh, well, I'm sorry, I should have clarified the context a bit more. Here
it is.
The link I provided here are Jehanne issues, not Plan 9 or 9front bug
reports.
After fixing a few of them I realized that, an year from now, I won't be
able to remember why I did the change. Also, coverity could shut
