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