[comp.lang.c] Accessing argc/argv/envp

davew@whuxm.UUCP (WONNACOTT) (07/27/87)

In article <420@sugar.UUCP>, peter@sugar.UUCP (Peter da Silva) writes:
> In article <28700015@ccvaxa>, aglew@ccvaxa.UUCP writes:
> > In standard C you cannot get access to argv/argc/envp without doing work
> > in main().
> 
> getenv()? putenv()? execl()? execv()? execlp()? execvp()?
> -- 
> -- Peter da Silva `-_-' ...!seismo!soma!uhnix1!sugar!peter (I said, NO PHOTOS!)

getenv() and putenv() access an external variable
	extern char **environ;
which starts out the same as envp, but may be changed by putenv().
You can also access environ directly from any function, but you
cannot legally get at argc, argv, or envp (as I understand standard C,
at least).

By the way, you should not use envp after putenv(), as putenv() does
not update envp (it can't).  If you need to get at the entire table
of environment variables after a putenv(), use environ instead.  In
fact, I've heard its a good idea to use environ instead of envp because
non-un*x systems are more likely to have environ than envp.

exec system calls do not access the argc and argv parameters of the
process that started them.  They do provide values which will become
arguments to the program that gets exec-ed, but thats a different story.

-- 
David Wonnacott			"They said Van Gogh was crazy, didn't they?"
whuxm!davew  or  rz3bb!davew
AT&T Corporate Education
The above opinions are not necessarily those of AT&T, or of anyone else anywhere

gwyn@brl-smoke.ARPA (Doug Gwyn ) (07/28/87)

In article <548@whuxm.UUCP> davew@whuxm.UUCP (WONNACOTT) writes:
>... I've heard its a good idea to use environ instead of envp because
>non-un*x systems are more likely to have environ than envp.

This business was juggled for a while by the IEEE P1003 and ANSI X3J11
standards committees.  The outcome was that an X3.159-compliant program
cannot expect envp, and furthermore it is possible that some
implementations simply cannot support both 2- and 3-argument main()
functions with a single approach.  (The latter argument is weakened by
the decision to allow a 0-argument main(), which would force special
compiler kludgery anyway.  I think 0-argument main() weakens the goal
of encouraging type correctness.)  The 2-argument form was chosen as
more in line with existing practice, plus we observed that the environ
variable provides a superset of the envp functionality.

peter@sugar.UUCP (Peter da Silva) (07/31/87)

> getenv() and putenv() access an external variable
> 	extern char **environ;
> which starts out the same as envp, but may be changed by putenv().
> You can also access environ directly from any function, but you
> cannot legally get at argc, argv, or envp (as I understand standard C,
> at least).

So... who sets up "environ". exec() certainly doesn't. It must be the 'C'
runtime. If so, is there any good reason something similar can't be set up
for "argv"? Maybe in ANSI 'C'?
-- 
-- Peter da Silva `-_-' ...!seismo!soma!uhnix1!sugar!peter (I said, NO PHOTOS!)

karl@haddock.ISC.COM (Karl Heuer) (08/06/87)

In article <450@sugar.UUCP> peter@sugar.UUCP (Peter da Silva) writes:
>> getenv() and putenv() access an external variable "environ".
>So... who sets up "environ". ... It must be the 'C' runtime.

Right.  In UNIX, it's the startup code in crt0.o.

>If so, is there any good reason something similar can't be set up for "argv"?

I'd prefer making just argv[0] global via "char *thisprogname" or something.
Accessing the whole list could be dangerous, and argv[0] is the only one
that's likely to be of interest to library routines.  No, there's no good
reason this can't be done.

>Maybe in ANSI 'C'?

No, their primary charter is to codify existing practice, which this isn't.
Ask your vendor for the feature.

Karl W. Z. Heuer (ima!haddock!karl or karl@haddock.isc.com), The Walking Lint