getenv() in global space?

[silrandir@gmail.com]

when attempting to call getenv() in global memory (c/c++), it
constantly returns null, but when called in main, it properly reads the
environment. is this expected behavior?

sample code:
#include <cstdlib>
#include <stdio.h>
#include <unistd.h>

using namespace std;
#define TEST "TEST"

int debug = getenv(TEST)?1: 0;

int main()
{
if(debugstr)
write(2, "\nTEST FOUND\n", 12);
else
write(2, "\nTEST NOT FOUND\n", 16);
}

[Keith Thompson]

Re: getenv() in global space?

silrandir@gmail .com writes:[color=blue]
> when attempting to call getenv() in global memory (c/c++), it
> constantly returns null, but when called in main, it properly reads the
> environment. is this expected behavior?
>
> sample code:
> #include <cstdlib>
> #include <stdio.h>
> #include <unistd.h>
>
> using namespace std;
> #define TEST "TEST"
>
> int debug = getenv(TEST)?1: 0;
>
> int main()
> {
> if(debugstr)
> write(2, "\nTEST FOUND\n", 12);
> else
> write(2, "\nTEST NOT FOUND\n", 16);
> }[/color]

Your code is C++, not C. comp.lang.c++ is down the hall on the right,
just past the water cooler.

In C, "All the expressions in an initializer for an object that has
static storage duration shall be constant expressions or string
literals" (C99 6.7.8p4), so your code can't even be translated
into correct C.

When you post to comp.lang.c++, I suggest you post the *actual* code
that you fed to your compiler; the code you posted declares "debug"
but tries to refer to "debugstr". I also suggest not using the
non-standard write() function; both C and C++ provide better and more
standard ways to print text.

(I don't know of any reason why getenv() would behave differently
depending on the context in which you call it, but maybe there's
something C++-specific that I don't know about.)

--
Keith Thompson (The_Other_Keit h) kst-u@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Alesak]

Re: getenv() in global space?

Hi,

that's funny, it works for me (linux, gcc 3.3.6, glibc 2.3.5). My guess
is that the full syntax of calling "main" is

int main (int argc, const char **argv, const char **envp);

that means that the pointer to environment buffer comes to the program
as a parameter of it's "main" function, then it should be put into the
"environ" global variable, which is accessed by "getenv". I am not sure
if it is clearly set for C++, what comes first - if the initialization
of global variables or this.

Sorry, that was nothing new

Ales

[Martin Ambuhl]

Re: getenv() in global space?

silrandir@gmail .com wrote:[color=blue]
> when attempting to call getenv() in global memory (c/c++), it
> constantly returns null, but when called in main, it properly reads the
> environment. is this expected behavior?
>
> sample code:
> #include <cstdlib>
> #include <stdio.h>
> #include <unistd.h>
>
> using namespace std;
> #define TEST "TEST"
>
> int debug = getenv(TEST)?1: 0;
>
> int main()
> {
> if(debugstr)
> write(2, "\nTEST FOUND\n", 12);
> else
> write(2, "\nTEST NOT FOUND\n", 16);
> }
>[/color]


/* Note that the term "global memory" has no meaning in either C or
C++, and that there is no such language as "c/c++". Since the term
"global memory" has no meaning, "when attempting to call getenv()
in global memory" is gibberish, and any question based on it is
meaningless. */

#if 0
#include <cstdlib> /* mha: no such standard C header */
#include <unistd.h> /* mha: no such standard C header */
using namespace std; /* mha: gibberish; syntax error */
int debug = getenv(TEST) ? 1 : 0; /* mha: intializers outside of
functions must be constant */
#endif

#include <stdlib.h> /* mha: added for getenv */
#include <stdio.h>

#define TEST "TEST"


int main()
{
int debug = getenv(TEST) ? 1 : 0; /* mha: intializers inside
functions do not need to be
constants */
/* mha: undefined identifier 'debugstr' changed, nonsensical use of
nonstandard function 'write' changed */
printf("\"TEST\ " %sfound\n", debug ? "" : "not ");
return 0; /* mha: added. Functions that promise
to return values should do so. This
broken C++ism of allowing dropping
off the end of main was added to the
C standard only in 1999 because of
the number of defective programmers
who kept violating the basic rule of
good sense. */
}

[Jordan Abel]

Re: getenv() in global space?

On 2006-02-23, Alesak <alesak@gmail.c om> wrote:[color=blue]
> Hi,
>[/color]
<OT>[color=blue]
> that's funny, it works for me (linux, gcc 3.3.6, glibc 2.3.5). My guess
> is that the full syntax of calling "main" is
>
> int main (int argc, const char **argv, const char **envp);
>
> that means that the pointer to environment buffer comes to the program
> as a parameter of it's "main" function, then it should be put into the
> "environ" global variable, which is accessed by "getenv". I am not sure
> if it is clearly set for C++, what comes first - if the initialization
> of global variables or this.[/color]

well, not quite. the environment buffer goes to the startup code, which
then sets up the pointers to it, puts that in environ, and passes
environ to main. Either way, it apparently happens after the phase which
is where your non-constant global initialization is being done
</OT>

[Micah Cowan]

Re: getenv() in global space?

silrandir@gmail .com writes:
[color=blue]
> when attempting to call getenv() in global memory (c/c++), it
> constantly returns null, but when called in main, it properly reads the
> environment. is this expected behavior?[/color]

Since you're in comp.lang.c, I'm going to assume the below snippet was
intended to be C code.

Also, given the content of your code, I think you meant "file scope"
where you said "global memory". The latter term doesn't have a defined
meaning here (nor at comp.lang.c++). A getenv() call in main() would
take place in "block scope".
[color=blue]
> #include <cstdlib>[/color]

Should be stdlib.h. And, at least be consistent. If you're going to
write C++ code, you should have done <cstdio> as well as <cstdlib>
(and, in that case, you should have posted to comp.lang.c++).
[color=blue]
> #include <stdio.h>
> #include <unistd.h>[/color]

unistd.h is not a Standard C header, and is thus not relevant to this
newsgroup. Similarly for the write() functions you use below.
[color=blue]
> using namespace std;[/color]

Meaningless in C.
[color=blue]
> #define TEST "TEST"
>
> int debug = getenv(TEST)?1: 0;[/color]

C does not allow you to make function calls in file-scope initializers
(or initializers for any other statically allocated object).
[color=blue]
> int main()
> {
> if(debugstr)[/color]

I'm assuming this is a typo: I'm gonna assume debug.
[color=blue]
> write(2, "\nTEST FOUND\n", 12);
> else
> write(2, "\nTEST NOT FOUND\n", 16);
> }[/color]

<OT>
Other than the typo, your program compiled /and/ executed as you
might expect as C++ code on a POSIX system.
</OT>

Aside from that: if you want to make it code that is generally
discussable on this newsgroup, you'll need to take the POSIXisms and
C++isms out, and after that you'll need to move the initialization
(and possibly, the definition) of debug into main() to get it to work
properly.

<OT>
Or, you can leave your code as is and move your question to
comp.unix.progr ammer. In that case, I'd still recommend you make a
consistent choice regarding <cstdlib> vs <stdlib.h>.
</OT>

-Micah