Environment Variables

[learner]

Hi,

What is the difference between accessing environment
variables through

int main(int argc,char *argv[],char *envp[])

and

extern char **environ;
Is there any advantage in any of the above two?

 

[Richard Bos]

What is the difference between accessing environment
variables through

int main(int argc,char *argv[],char *envp[])

and

extern char **environ;
Is there any advantage in any of the above two?

No. Both are obsolete, non-ISO ways of trying to read environment
variables, and you may run into portability problems using either of
them. The proper way to read an environment variable in portable,
ISO-Standard C is to use the getenv() functions.

Richard

 

[Ralmin]

Hi,

What is the difference between accessing environment
variables through

int main(int argc,char *argv[],char *envp[])

and

extern char **environ;

No difference, they are both non-standard and unportable. In fact, environ
is not a reserved identifier so any attempt by the implementation to supply
a definition of it, let alone any value other than the usual null-pointer
initialisation, would be improper.

Cygwin's GCC 3.3.1 appears to have a bug! If I try to define my own extern
variable, I get this error:
/usr/lib/gcc-lib/i686-pc-cygwin/3.3.1/../../../libcygwin.a(_cygwin_crt0_comm
on.o)(.bss+0x0): multiple definition of `_environ'
/cygdrive/c/DOCUME~1/SIMONB~1/LOCALS~1/Temp/ccMMv8Qk.o(.data+0x0):environ2.c
: first defined here

I should be allowed to create my own 'extern' variable -- the name is not
reserved.

MS's CL 13.10.3052 does provide a definition of environ, but its linker also
allows me to create my own, which overrides the internal one. This is
probably standard-conforming under the 'as-if' rule.

Borland BCC32 5.5.1 correctly gives an error if environ is used but not
defined:
Error: Unresolved external '_environ' referenced from
C:\DOCUMENT\PROG\C\ENVIRON.OBJ

LCC-Win32 correctly behaves like bcc32, in that I get a linker error that
environ is not defined:
environ.obj .text: undefined reference to '_environ'
linker returned 2
but for some weird reason it goes on to create an executable anyway! The
executable crashes, for what it's worth.

Is there any advantage in any of the above two?

No. I suggest you use the standard C solution, which is a library function:
char *getenv(const char *name);

It will search the list for an environment variable of the name given, and
return a pointer to a string containing the value of that variable. If the
name is not found, a null pointer will be returned.

 

[Michael Wojcik]

What is the difference between accessing environment
variables through

int main(int argc,char *argv[],char *envp[])

and

extern char **environ;
Is there any advantage in any of the above two?

No. Both are obsolete, non-ISO ways of trying to read environment
variables,

While environ is not part of ISO 9899, the C standard, it is included
in ISO 9945 (POSIX), and hence "non-ISO" could be misleading. While
comp.lang.c deals specifically with ISO 9899, useful programs generally
have to operate in part outside the scope of that standard, so it is
often useful to point out when such operation is covered under another
standard, which may apply to the user's implementation.

and you may run into portability problems using either of
them. The proper way to read an environment variable in portable,
ISO-Standard C is to use the getenv() functions.

I believe it's worth noting that in fact there is an advantage to the
POSIX environ mechanism over the C getenv one, and so environ is by
no means "obsolete". environ permits iterating over all the values in
the environment list; getenv does not. (environ thus presupposes
that the environment list supports iteration in some meaningful way,
which C does not require, of course.)

Iterating over the environment list is an important feature for some
programs in some environments. (In some of these it is useful for
security purposes, for example.)

--
Michael Wojcik (e-mail address removed)

I will shoue the world one of the grate Wonders of the world in 15
months if Now man mourders me in Dors or out Dors
-- "Lord" Timothy Dexter, _A Pickle for the Knowing Ones_

 

[CBFalconer]

.... snip ...

No difference, they are both non-standard and unportable. In fact,
environ is not a reserved identifier so any attempt by the
implementation to supply a definition of it, let alone any value
other than the usual null-pointer initialisation, would be improper.

Cygwin's GCC 3.3.1 appears to have a bug! If I try to define my own
extern variable, I get this error:
/usr/lib/gcc-lib/i686-pc-cygwin/3.3.1/../../../libcygwin.a(_cygwin_crt0_comm
on.o)(.bss+0x0): multiple definition of `_environ'
/cygdrive/c/DOCUME~1/SIMONB~1/LOCALS~1/Temp/ccMMv8Qk.o(.data+0x0):environ2.c
: first defined here

I should be allowed to create my own 'extern' variable -- the name
is not reserved.

Are you sure you are using gcc as a standard C compiler? That
requires the use of -ansi -pedantic, which should be routine
together with -W -Wall.

In the default GNU C configuration 'environ' may well be used.

--
"I'm a war president. I make decisions here in the Oval Office
in foreign policy matters with war on my mind." - Bush.
"Churchill and Bush can both be considered wartime leaders, just
as Secretariat and Mr Ed were both horses." - James Rhodes.
"If I knew then what I know today, I would still have invaded
Iraq. It was the right decision" - G.W. Bush, 2004-08-02

 

[Ralmin]

Are you sure you are using gcc as a standard C compiler? That
requires the use of -ansi -pedantic, which should be routine
together with -W -Wall.

In the default GNU C configuration 'environ' may well be used.

Yes, that was with my normal gcc command line:
gcc -ansi -pedantic -Wall -W -O2

I get the same error with plain 'gcc' and with 'gcc -ansi -pedantic' as
well.

Perhaps the -ansi and -pedantic options affect only the compiler, not the
linker.

Perhaps it is a bug in libcygwin.a -- that the symbol _environ should be
made 'weak' so it is overridden by the user supplied one, if any.

Since this is off-topic here in comp.lang.c, I suppose I should see if I can
find an appropriate channel to ask the Cygwin people about it.

 

[Ralmin]

I thought of it another way... take for example this program:

#include <stdio.h>

int environ;

int main(void)
{
printf("%d\n", environ);
return 0;
}

According to the standard, the above contains a definition of the variable
environ, with external linkage and static storage, right? It should be
therefore be initialised to zero.

On MS C/C++, LCC-Win32, Borland C++ compilers it is initialised to zero.
However, on Cygwin/GCC 3.3.1 I get 168100008, which happens to be the
address of the environment list, as I can see if I add in the line:

for(char **p = (char **)environ; *p; p++) puts(*p);

Since this program is accepted by the linker of Cygwin/GCC, it must be
taking the line as just a declaration of environ, not a definition.

If I change the line to
int environ = 1;

Then the linker barfs again:
C:\>gcc -std=c99 -pedantic -Wall -W -O2 env.c -o env
/usr/lib/gcc-lib/i686-pc-cygwin/3.3.1/../../../libcygwin.a_c
ygwin_crt0_common.o)(.bss+0x0): multiple definition of `_env
iron'
/cygdrive/c/DOCUME~1/SIMONB~1/LOCALS~1/Temp/ccWOu7SU.o(.data
+0x0):env.c: first defined here
collect2: ld returned 1 exit status

I guess it is no longer able to see it as just a declaration, but there are
two definitions of environ and the linker cannot tell which one is correct.

 

[CBFalconer]

I thought of it another way... take for example this program:

#include <stdio.h>

int environ;

int main(void)
{
printf("%d\n", environ);
return 0;
}

According to the standard, the above contains a definition of the
variable environ, with external linkage and static storage, right?
It should be therefore be initialised to zero.

I agree with you, provided you use -ansi -pedantic. That prints a
non-zero value here under DJGPP 2.03 and gcc 3.2.1. Since you
have the problem under cygwin (I believe) and it doesn't appear to
be system library/header specific, I suggest YOU file a bug report
with gnu. "info gcc bugs" or "gcc --help" will tell you how to
file.

I am cross-posting this to comp.os.msdos.djgpp.

--
"I'm a war president. I make decisions here in the Oval Office
in foreign policy matters with war on my mind." - Bush.
"Churchill and Bush can both be considered wartime leaders, just
as Secretariat and Mr Ed were both horses." - James Rhodes.
"If I knew then what I know today, I would still have invaded
Iraq. It was the right decision" - G.W. Bush, 2004-08-02

 

[CBFalconer]

I agree with you, provided you use -ansi -pedantic. That prints a
non-zero value here under DJGPP 2.03 and gcc 3.2.1. Since you
have the problem under cygwin (I believe) and it doesn't appear to
be system library/header specific, I suggest YOU file a bug report
with gnu. "info gcc bugs" or "gcc --help" will tell you how to
file.

I am cross-posting this to comp.os.msdos.djgpp.

Changing the 'environ' name makes things become correct. gcc
seems to be creating a parameter to main, which is being accessed
by the identifier environ, even though the parameters are
specified to be void. gcc -E creates no reference to 'environ'.

I suspect there may be similar problems with argv and/or argc
replacing environ in the same program.

--
"I'm a war president. I make decisions here in the Oval Office
in foreign policy matters with war on my mind." - Bush.
"Churchill and Bush can both be considered wartime leaders, just
as Secretariat and Mr Ed were both horses." - James Rhodes.
"If I knew then what I know today, I would still have invaded
Iraq. It was the right decision" - G.W. Bush, 2004-08-02

 

[Dan Henry]

Not that I agree or disagree...

But could we please keep comp.' newsgroups free of political drivel?
I get enough of that with the rock and movie stars (and "<!-- insert
agenda-driven-group -->) opinionating. Must we (I) get it here too?

Just a suggestion -- if y'all want it, go for it!

 

[Dan Henry]

<!-- As signature -->
"I'm a war president. I make decisions here in the Oval Office
in foreign policy matters with war on my mind." - Bush.
"Churchill and Bush can both be considered wartime leaders, just
as Secretariat and Mr Ed were both horses." - James Rhodes.
"If I knew then what I know today, I would still have invaded
Iraq. It was the right decision" - G.W. Bush, 2004-08-02

Sorry, the above is what I was replying to, and now...

Not that I agree or disagree...

But could we please keep c.a.e free of political drivel? I get enough
of that with the rock and movie stars (and "<!-- insert
agenda-driven-group -->) opinionating. Must we (I) get it here too?

Just a suggestion -- if y'all want it, go for it!

 

[Jens.Toerring]

Sorry, the above is what I was replying to, and now...

Not that I agree or disagree...

But could we please keep c.a.e free of political drivel? I get enough
of that with the rock and movie stars (and "<!-- insert
agenda-driven-group -->) opinionating. Must we (I) get it here too?

Just a suggestion -- if y'all want it, go for it!

I guess it would be more clever to get yourself a newsreader that
simply lets you keep signatures from getting displayed - it's not
part of the message, so you won't get cheated out of any relevant
information. And since CBFalconer's signature starts with the cor-
rect "-- \n" sequence every halfway decent newsreader should be
able to hide it from you.
Regards, Jens

 

[CBFalconer]

.... snip ...


I guess it would be more clever to get yourself a newsreader that
simply lets you keep signatures from getting displayed - it's not
part of the message, so you won't get cheated out of any relevant
information. And since CBFalconer's signature starts with the cor-
rect "-- \n" sequence every halfway decent newsreader should be
able to hide it from you.

It was too long, and I have cut it back. It changes from time to
time anyhow. Anyhow, what politics? All it does is quote
GWB! (after cutback).

 

[Keith Thompson]

Sorry, the above is what I was replying to, and now...

Not that I agree or disagree...

But could we please keep c.a.e free of political drivel? I get enough
of that with the rock and movie stars (and "<!-- insert
agenda-driven-group -->) opinionating. Must we (I) get it here too?

Just a suggestion -- if y'all want it, go for it!

Signatures are traditionally not considered part of the message, and
are not subject to topicality rules.

 

[Dan Henry]

(e-mail address removed)-berlin.de wrote:

===snip===

I guess it would be more clever to get yourself a ...
... halfway decent newsreader

Yep, Agent -- how silly of me not knowing it was the lower-half of a
fully decent newsreader.

 

[kal]

I guess it would be more clever to get yourself a newsreader that
simply lets you keep signatures from getting displayed ...

Yes, that is true. Still, it is nicer not to be offensive.

I find the sig. somewhat funny. What is funny is that it makes
an implicit assumption that Secretariat is somehow superior to
Mr. Ed. What if the assumption is wrong?

 

[Hans-Bernhard Broeker]

[F'up2 c.l.c, because the ball is safely back in their playing field.]

I agree with you, provided you use -ansi -pedantic.

You don't need -pedantic in this case. What you need is the effect of
-ansi turning off all extensions present in the compiler's runtime
library, compared to the C standard. In other words, you need a clean
namespace for the above program to reliably print zero, and that's
what -ansi is meant to give you.

On a more relaxed note, you can ask gcc to warn you in situations like
this, while still keeping the full functionality of the standard libc
intact, by using the -fno-common option. In terms of the standard:
-fno-common turns off the usual Unix linkers' extension of allowing
tentative definitions to be resolved across the entire program, not
just individual translation units.

This problem is actually a comp.lang.c FAQ, and addressed in the C
FAQ. Usually it happens with the name 'index', which exists in Unix
libc, is not an ANSI/ISO standard C library function, but is *very*
tempting to use as the name of some object in your own source code,
until you run into this the first time. Go figure.

 

[Alan Balmer]

Yes, that is true. Still, it is nicer not to be offensive.

I find the sig. somewhat funny. What is funny is that it makes
an implicit assumption that Secretariat is somehow superior to
Mr. Ed. What if the assumption is wrong?

I thought the implication was that Bush could talk better than
Churchill.

 

[CBFalconer]

FWIW below is a list of library symbols that pollute the user global
namespace in *ALL* C programs and are not mentioned in the libc
documentation.
It was produced by compiling and linking a small dummy program, then
running nm -Cg, stripping the addresses, and editing out the
documented names.
The first letter tells you whether it's defined in a text, data or bss
segment.

D djgpp_first_ctor
D djgpp_first_dtor
D djgpp_last_ctor
D djgpp_last_dtor
D edata
B end
B environ
T etext
B exception_stack
T start

ISTM that a reasonable first step would be to document the existence
of these symbols in the libc documentation, and possibly add useful
public interfaces to some header file, perhaps only for the case of
environ, which seems to be the only symbol likely to be accessed by
user level code.

.... snip possible djgpp temporary fix ...

I am taking the liberty of crossposting this to c.l.c, where the
problem originally arose, with follow-ups set to c.l.c. I think
this is appropriate because you have created a generalized method
of seeing the extent of the problem, for which thanks, at least in
the unix/posix world.

 

[Brian Inglis]

... snip possible djgpp temporary fix ...

I am taking the liberty of crossposting this to c.l.c, where the
problem originally arose, with follow-ups set to c.l.c. I think
this is appropriate because you have created a generalized method
of seeing the extent of the problem, for which thanks, at least in
the unix/posix world.

I did it under DJGPP, which is part of the POSIX world!