> Danny Braniss wrote:
>
> > now why would FreeBSD supply sources?
> > from /usr/src/lib/libc/stlib/getenv.c:
> > ...
>
> Thanks I have the source but actually checking the call programatically
> should be better since since it does not rely on my interpretation
> of code. It also does not help
Danny Braniss wrote:
now why would FreeBSD supply sources?
from /usr/src/lib/libc/stlib/getenv.c:
...
Thanks I have the source but actually checking the call programatically
should be better since since it does not rely on my interpretation
of code. It also does not help me understand the pro
Thanks for the reference. As I read it FreeBSD is following
standard (no surprise ;-) but it would appear other platforms
may not be. I'll check this out when I get access to a linux
box.
Joseph Koshy wrote:
From "The Open Group Base Specifications Issue 6"
http://www.cnop.net/docs/susv3/fun
h). I believe its the
> way the code get the environment variables that is the cause. But if
> thats the case then it would appear that getenv semantics differs
> slightly on different platforms.
>
> From http://notabug.com/2002/coherent/man/getenv.html
> "When VARI
> Is this analysis correct? Can someone point me to the (a?)
> standard that describes this. The FreeBSD behaviour makes
> sense, I am trying to understand what is the expected
> behaviour on other platforms.
>From "The Open Group Base Specifications Issue 6"
http://www.cnop.net/docs/susv3/funct
code get the environment variables that is the cause. But if
thats the case then it would appear that getenv semantics differs
slightly on different platforms.
From http://notabug.com/2002/coherent/man/getenv.html
"When VARIABLE is not found or has no value, getenv() returns NULL.&quo
6 matches
Mail list logo
