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]

"learner" <v_********@yahoo.com> wrote:

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]

"learner" <v_********@yahoo.com> wrote:

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.

--
Simon.

[Michael Wojcik]

In article <41****************@news.individual.net>, rl*@hoekstra-uitgeverij.nl (Richard Bos) writes:

"learner" <v_********@yahoo.com> wrote:

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 mi************@microfocus.com

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]

Ralmin wrote:

.... snip ...

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.

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]

"CBFalconer" <cb********@yahoo.com> wrote:

Ralmin wrote:

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_common.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.

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.

--
Simon.

[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.

--
Simon.

[CBFalconer]

Ralmin wrote:

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]

CBFalconer wrote:

Ralmin wrote:

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.

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]

CBFalconer <cb********@yahoo.com> wrote:

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

[Dan Henry]

CBFalconer <cb********@yahoo.com> wrote:

<!-- 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!

--
Dan Henry

[Jens.Toerring]

In comp.lang.c Dan Henry <dh****@sprynet.com> wrote:

CBFalconer <cb********@yahoo.com> wrote:

<!-- 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!

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
--
\ Jens Thoms Toerring ___ Je***********@physik.fu-berlin.de
\__________________________ http://www.toerring.de

[CBFalconer]

Je***********@physik.fu-berlin.de wrote:

In comp.lang.c Dan Henry <dh****@sprynet.com> wrote:
.... snip ...

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?

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).

--
"The most amazing achievement of the computer software industry
is its continuing cancellation of the steady and staggering
gains made by the computer hardware industry..." - Petroski

[Keith Thompson]

Dan Henry <dh****@sprynet.com> writes:

CBFalconer <cb********@yahoo.com> wrote:

<!-- 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!

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

--
Keith Thompson (The_Other_Keith) ks***@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.

[Dan Henry]

Je***********@physik.fu-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.

--
Dan Henry

[kal]

Je***********@physik.fu-berlin.de wrote in message news:<2n***********@uni-berlin.de>...

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.]

In comp.os.msdos.djgpp CBFalconer <cb********@yahoo.com> wrote:

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.

--
Hans-Bernhard Broeker (br*****@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.

[Alan Balmer]

On 6 Aug 2004 01:20:51 -0700, k_*****@yahoo.com (kal) wrote:

Je***********@physik.fu-berlin.de wrote in message news:<2n***********@uni-berlin.de>...

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?

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

--
Al Balmer
Balmer Consulting
re************************@att.net

[CBFalconer]

Brian Inglis wrote:

in comp.os.msdos.djgpp, "Eli Zaretskii" <el**@gnu.org> wrote:

From: CBFalconer <cb********@yahoo.com>
Newsgroups: comp.lang.c,comp.os.msdos.djgpp
Date: Thu, 05 Aug 2004 23:27:28 GMT

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'.

`environ' is a symbol that comes from the library. It is a pointer to
an array of char *, where each array element is a string of the form
"foo=bar": these are the environment variables and their values.

I guess if this happens even under "-ansi -pedantic", it's a bug that
we pollute the ANSI namespace with a non-ANSI symbol that doesn't bgin
with an underscore. But given that Unix programs expect that symbol,
I'm not sure we can change that.

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.

--
"The most amazing achievement of the computer software industry
is its continuing cancellation of the steady and staggering
gains made by the computer hardware industry..." - Petroski

[Brian Inglis]

On Sat, 07 Aug 2004 01:01:44 GMT in comp.os.msdos.djgpp, CBFalconer
<cb********@yahoo.com> wrote:

Brian Inglis wrote:

in comp.os.msdos.djgpp, "Eli Zaretskii" <el**@gnu.org> wrote:

From: CBFalconer <cb********@yahoo.com>
Newsgroups: comp.lang.c,comp.os.msdos.djgpp
Date: Thu, 05 Aug 2004 23:27:28 GMT

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'.

`environ' is a symbol that comes from the library. It is a pointer to
an array of char *, where each array element is a string of the form
"foo=bar": these are the environment variables and their values.

I guess if this happens even under "-ansi -pedantic", it's a bug that
we pollute the ANSI namespace with a non-ANSI symbol that doesn't bgin
with an underscore. But given that Unix programs expect that symbol,
I'm not sure we can change that.

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.

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

--
Thanks. Take care, Brian Inglis Calgary, Alberta, Canada

Br**********@CSi.com (Brian dot Inglis at SystematicSw dot ab dot ca)
fake address use address above to reply

[Emmanuel Delahaye]

learner wrote on 04/08/04 :

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?

None of them are standard.

The canonical forms of main() are

int main (void)

and

int main (int, char **)

If you want to read an environment variable, you have getenv().

--
Emmanuel
The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html

"C is a sharp tool"

[Emmanuel Delahaye]

Ralmin wrote on 05/08/04 :

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.

Probably, yes. Chances are that the 'environ' global variable belong to
the C-library (like 'errno' is) and the compiler is not aware of that.

--
Emmanuel
The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html

"C is a sharp tool"

[Emmanuel Delahaye]

(supersedes <mn***********************@YOURBRAnoos.fr>)

Ralmin wrote on 05/08/04 :

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.

Probably, yes. Chances are that the 'environ' global variable belong to
the C-library (like 'errno' does) and that the compiler is not aware of
that.

--
Emmanuel
The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html

"C is a sharp tool"

[Michael Wojcik]

In article <lj********************************@4ax.com>, Alan Balmer <al******@att.net> writes:

On 6 Aug 2004 01:20:51 -0700, k_*****@yahoo.com (kal) wrote:

Je***********@physik.fu-berlin.de wrote in message news:<2n***********@uni-berlin.de>...

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.

That's debatable. While it is arguably "nicer" by definition in the
scope of the immediate interpersonal exchage to avoid offense, it's
conceivable that over a longer term greater benefit may accrue to the
offended party through that offense, so the overall nicer course of
action is to offend. Indeed, a great many social practices are
predicated on this notion, and we see them practiced daily on Usenet.

Further, it's conceivable that by offending one member of the audience,
that member may be driven from the discussion, to the gratification of
several other audience members; and so a net gain in niceness is
achieved through offense. We see this attempted daily on Usenet, with
limited success.
I thought the implication was that Bush could talk better than
Churchill.

Yes, but only when his trainer puts peanut butter in his mouth.

--
Michael Wojcik mi************@microfocus.com

Vinegar keeps more flies away than honey does.

[CBFalconer]

Emmanuel Delahaye wrote:

Ralmin wrote on 05/08/04 :

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.

Probably, yes. Chances are that the 'environ' global variable
belong to the C-library (like 'errno' does) and that the compiler
is not aware of that.

There are usually many things in the library that are not
specified in the standard, or in the system namespace. However
they should be in modules that do not get loaded unless requested,
and thus should not interfere.

--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!

[Chris Torek]

[on the name "environ" cluttering up the namespace even under -ansi
mode in various systems]

Emmanuel Delahaye wrote:

Probably, yes. Chances are that the 'environ' global variable
belong to the C-library (like 'errno' does) and that the compiler
is not aware of that.

(This is correct.)

In article <41***************@yahoo.com>,
CBFalconer <cb********@worldnet.att.net> wrote:There are usually many things in the library that are not
specified in the standard, or in the system namespace. However
they should be in modules that do not get loaded unless requested,
and thus should not interfere.

Unfortunately, this is "too difficult" (for some value of "too",
or perhaps some definition of "difficult") to achieve on those
systems. The reason is that they use a single startup module
that looks sort of like this (pseudo-C):

void __start(void) {
register struct os_supplied_startup_info *p __asm__("some magic here");
int argc;
char **argv, **envp;
extern char **environ;
int i;

/*
* Often there is actually more than just "argv data" here.
* Some systems provide argc as well, and some provide info
* on loading libraries, O/S version, and/or other special
* stuff.
*/
argv = p->argv_data;
for (i = 0; argv[i] != NULL; i++)
continue; /* nothing else to do here */
argc = i;
environ = envp = &argv[i];
__more_library_initialization(); /* e.g., stdin/stdout/stderr etc */
exit(main(argc, argv, envp));
__asm__("more magic here if needed, but probably not reachable");
}

Note that this startup module calls main() with three arguments,
rather than the appropriate two-or-zero, and depends on the fact
that the underlying system "just happens" to have that work. (The
system in this case is i386 or SPARC or VAX or MIPS or PowerPC or
ARM or ... well, perhaps I should just say that the list of machines
on which it does NOT work is a LOT shorter :-) than the list of
machines where it DOES work. Those of us who write startup code,
however, are prepared to rewrite it when we encounter such machines.
Since the __asm__ contents change from one machine to the next
anyway, and since this code sometimes has to be written in assembly,
it is not that important.)

Unfortunately, this startup module also refers to a global variable
named "environ", because the system-supplied C library does the
same (in getenv()).

The fix (in this case) is not to avoid loading certain modules,
but rather to rename the global variable, e.g., change it to
__environ. For backwards compatibility, these (ELF-based) systems
provide a "weak association" directive under which the "true name"
(now __environ) can be "loosely attached" to the old, intrusive
"environ" name. If the programmer supplies any instance of "environ",
the programmer's version breaks the weak attachment so that the
system's __environ is an entirely separate variable; but if the
program only ever says "extern char **environ;" -- only refers to
it, rather than defining it -- the weak link holds and the old code
continues to compile and link.
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) [phone]
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.

[CBFalconer]

Chris Torek wrote:

.... snip ...
Unfortunately, this startup module also refers to a global variable
named "environ", because the system-supplied C library does the
same (in getenv()).

The fix (in this case) is not to avoid loading certain modules,
but rather to rename the global variable, e.g., change it to
__environ. For backwards compatibility, these (ELF-based) systems
provide a "weak association" directive under which the "true name"
(now __environ) can be "loosely attached" to the old, intrusive
"environ" name. If the programmer supplies any instance of "environ",
the programmer's version breaks the weak attachment so that the
system's __environ is an entirely separate variable; but if the
program only ever says "extern char **environ;" -- only refers to
it, rather than defining it -- the weak link holds and the old code
continues to compile and link.

I think the proper thing here is to have the startup module
variable, etc. named __environ (or something else in the system
space). This is used to place the appropriate data in the
appropriate place on the stack (assuming a stack), and is
published in the startup modules exported names.

Now, somewhere in the process of compiler startup, it knows
whether it is an ansi or extended compiler. If extended, it calls
code like:

genline("#define environ __environ\n");

which magically moves the item into the users namespace.

I can see complications because this should probably be local to
main, and I gather from some other posts that "environ" must not
appear in the system headers per POSIX. However I would consider
the first requirement to be "make it C99 compliant", and full
POSIX compliancy is subordinate.

The proper way would be to have an added header for POSIX
standard, which could handle all these silly differences. Just
omit it to strip the POSIX stuff. IMHO.

--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!