is this stadard C?

[Lowell Kirsh]

I saw something recently for the first time:

int main(int argc, char **argv, char **envp)
^
The thing I had never seen was a third arg to the main function. I
thought main either took no args or 2 args. Is this not the case?

Lowell

[Gregory Toomey]

Lowell Kirsh wrote:

I saw something recently for the first time:

int main(int argc, char **argv, char **envp)
^
The thing I had never seen was a third arg to the main function. I
thought main either took no args or 2 args. Is this not the case?

Lowell

Its used for environment variables, which is a standard unix feature.

Subprocesses "inherit" the parents environment, and this can be used as a
simple interprocess communications mechanism.
gtoomey
www.gregorytoomey.com

[Dave Vandervies]

In article <cv**********@mughi.cs.ubc.ca>,
Lowell Kirsh <lk****@cs.ubc.ca> wrote:

I saw something recently for the first time:

int main(int argc, char **argv, char **envp)
^
The thing I had never seen was a third arg to the main function. I
thought main either took no args or 2 args. Is this not the case?

This is the case for strictly conforming programs compiled under a
hosted implementation.

A platform can let you define main any way it wants to let you,
since defining it in any way other than
int main(void)
or
int main(int argc,char **argv)
frees the compiler from the requirements placed on it by the standard
(in standardese, it invokes undefined behavior), so it can do anything
(including, as the most frequent case, almost what it would have done
if you'd used the correct definition).
C99 attempted to legitimize this by saying that, in addition to the two
standard definitions of main, it can also be defined in "some other
implementation-defined manner"; this really doesn't change anything,
though - you're still stepping outside the language it defines if you
have a main() that returns anything other than int or takes anything
other than no arguments or the two specified by the standard.

In this particular case, a third pointer as an argument to main is a
(somewhat archaic) unixism that points to a collection of environment
variables. The standard-conforming way to get at these is to use
getenv(), and POSIX also gives you putenv() to set them (I'm not sure
if that's possible through the envp pointer).
dave

--
Dave Vandervies dj******@csclub.uwaterloo.ca
I suppose automatic updates will also install the additional memory I need
to get reasonable performance.
--Alex Colvin in comp.arch

[Ben Pfaff]

Lowell Kirsh <lk****@cs.ubc.ca> writes:

I saw something recently for the first time:

int main(int argc, char **argv, char **envp)
^
The thing I had never seen was a third arg to the main function. I
thought main either took no args or 2 args. Is this not the case?

Yes, main() may only be portably defined with zero or two
parameters. Some versions of Unix allow a third parameter for
main(), but this is not standard even among Unix variants.
--
"I should killfile you where you stand, worthless human." --Kaz

[E. Robert Tisdale]

Lowell Kirsh wrote:

I saw something recently for the first time:

int main(int argc, char **argv, char **envp)
^
The thing I had never seen was a third arg to the main function.
I thought main either took no args or 2 args.
Is this not the case? cat main.c int main(int argc) {
return 0;
}
gcc -Wall -std=c99 -pedantic -o main main.c main.c:1: warning: 'main' takes only zero or two arguments vi main.c
cat main.c int main(int argc, float x) {
return 0;
}
gcc -Wall -std=c99 -pedantic -o main main.c main.c:1: warning: second argument of 'main' should be 'char **' vi main.c
cat main.c int main(int argc, char* argv[], float x) {
return 0;
}
gcc -Wall -std=c99 -pedantic -o main main.c main.c:1: warning: third argument of 'main' should probably be
'char **' vi main.c
cat main.c int main(int argc, char* argv[], char* envp[], float x) {
return 0;
}
gcc -Wall -std=c99 -pedantic -o main main.c

main.c:1: warning: 'main' takes only zero or two arguments

[E. Robert Tisdale]

Lowell Kirsh wrote:

I saw something recently for the first time:

int main(int argc, char **argv, char **envp) cat main.c #include <stdio.h>

int main(int argc, char* argv[], char* envp[]) {
size_t j = 0;
while (NULL != envp[j])
fprintf(stdout, "%s\n", envp[j++]);
return 0;
}
gcc -Wall -std=c99 -pedantic -o main main.c
./main

[Lowell Kirsh]

Thank you all for your answers. I get the impression that using this
form is pretty unnecessary. It seems like using getenv would be a better
solution in most cases.

Lowell

Lowell Kirsh wrote:

I saw something recently for the first time:

int main(int argc, char **argv, char **envp)
^
The thing I had never seen was a third arg to the main function. I
thought main either took no args or 2 args. Is this not the case?

Lowell

[Richard Tobin]

In article <87************@benpfaff.org>,
Ben Pfaff <bl*@cs.stanford.edu> wrote:

Yes, main() may only be portably defined with zero or two
parameters. Some versions of Unix allow a third parameter for
main(), but this is not standard even among Unix variants.

I find that hard to believe. What unix does it not work on?

-- Richard

[Alan Balmer]

On Tue, 22 Feb 2005 02:19:57 -0800, Lowell Kirsh <lk****@cs.ubc.ca>
wrote:

Thank you all for your answers. I get the impression that using this
form is pretty unnecessary. It seems like using getenv would be a better
solution in most cases.
If you know the name of the environment variable you're looking for,
yes, it's easier to use getenv(). If, for some reason, you wanted to
search the environment variables, the "char *env[]" form would be the
way to do it.
Lowell

Lowell Kirsh wrote:

I saw something recently for the first time:

int main(int argc, char **argv, char **envp)
^
The thing I had never seen was a third arg to the main function. I
thought main either took no args or 2 args. Is this not the case?

Lowell

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

[Ben Pfaff]

ri*****@cogsci.ed.ac.uk (Richard Tobin) writes:

In article <87************@benpfaff.org>,
Ben Pfaff <bl*@cs.stanford.edu> wrote:

Yes, main() may only be portably defined with zero or two
parameters. Some versions of Unix allow a third parameter for
main(), but this is not standard even among Unix variants.

I find that hard to believe. What unix does it not work on?

It does not matter where it works or not. It is not standard
because it is not in SuSv3 or other modern Unix standards.
--
"...deficient support can be a virtue.
It keeps the amateurs off."
--Bjarne Stroustrup

[Keith Thompson]

Alan Balmer <al******@att.net> writes:

On Tue, 22 Feb 2005 02:19:57 -0800, Lowell Kirsh <lk****@cs.ubc.ca>
wrote:

Thank you all for your answers. I get the impression that using this
form is pretty unnecessary. It seems like using getenv would be a better
solution in most cases.

If you know the name of the environment variable you're looking for,
yes, it's easier to use getenv(). If, for some reason, you wanted to
search the environment variables, the "char *env[]" form would be the
way to do it.

<OT>
Passing the extra parameter to main() is one way to do it. Another is
(I think) declaring "extern char *environ[];". The latter is cleaner,
IMHO. Both, of course, are non-standard.
</OT>

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

[E. Robert Tisdale]

Keith Thompson wrote:

Passing the extra parameter to main() is one way to do it.
Another is (I think) declaring "extern char *environ[];".
The latter is cleaner, IMHO.
Both, of course, are non-standard.

getenv(const char *) *is* standard
but you must know the environment variable name
that you are looking for.

[Keith Thompson]

"E. Robert Tisdale" <E.**************@jpl.nasa.gov> writes:

Keith Thompson wrote:

Passing the extra parameter to main() is one way to do it.
Another is (I think) declaring "extern char *environ[];".
The latter is cleaner, IMHO.
Both, of course, are non-standard.

getenv(const char *) *is* standard
but you must know the environment variable name
that you are looking for.

Yes, thank you for restating the obvious. In Alan Balmer's previous
article, to which I was responding, he wrote (and I quoted):

] If you know the name of the environment variable you're looking for,
] yes, it's easier to use getenv(). If, for some reason, you wanted to
] search the environment variables, the "char *env[]" form would be
] the way to do it.

You also snipped the "<OT>" and "</OT>" tags I had placed around my
comments.

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

[Villy Kruse]

On Tue, 22 Feb 2005 08:38:40 -0700,
Alan Balmer <al******@att.net> wrote:

If you know the name of the environment variable you're looking for,
yes, it's easier to use getenv(). If, for some reason, you wanted to
search the environment variables, the "char *env[]" form would be the
way to do it.

If you realy want to do that then use the global variable environ.
The third paramter passed to main in unix won't stay valid after
you have modified the environment. So even on unix it is better
to pretend that the third argument to main doesn't exist. The
ANSI C standard doesn't, however, provide any standard for changing the
environment, let alone the existense or non-existence of the environ
global variable.

Villy

[infobahn]

Villy Kruse wrote:

On Tue, 22 Feb 2005 08:38:40 -0700,
Alan Balmer <al******@att.net> wrote:

If you know the name of the environment variable you're looking for,
yes, it's easier to use getenv(). If, for some reason, you wanted to
search the environment variables, the "char *env[]" form would be the
way to do it.

If you realy want to do that then use the global variable environ.

Not if you want your code to stay portable.
The third paramter passed to main in unix won't stay valid after
you have modified the environment. So even on unix it is better
to pretend that the third argument to main doesn't exist. The
ANSI C standard doesn't, however, provide any standard for changing the
environment, let alone the existense or non-existence of the environ
global variable.

Precisely.

[Lawrence Kirby]

On Wed, 23 Feb 2005 09:08:30 +0000, infobahn wrote:

Villy Kruse wrote:

On Tue, 22 Feb 2005 08:38:40 -0700,
Alan Balmer <al******@att.net> wrote:

> If you know the name of the environment variable you're looking for,
> yes, it's easier to use getenv(). If, for some reason, you wanted to
> search the environment variables, the "char *env[]" form would be the
> way to do it.
>

If you realy want to do that then use the global variable environ.

Not if you want your code to stay portable.

Using either method (environ or 3 argument main) makes your code
non-portable as far as standard C is concerned. extern char **environ is
at least defined by POSIX and as such would have to be considered more
portable. Using the 3 argument form of main() will probably compile and
link successfully on more platforms, it just means that where it isn't
supported it misbehaves at runtime rather than fails to compile, which is
worse.

The third paramter passed to main in unix won't stay valid after
you have modified the environment. So even on unix it is better
to pretend that the third argument to main doesn't exist. The
ANSI C standard doesn't, however, provide any standard for changing the
environment, let alone the existense or non-existence of the environ
global variable.

Precisely.

getenv() is the portable way to get environment strings. But if you need
more than it can offer, environ is a better bet than 3 argument main.
While both are outside the scope of standard C I think it is worth
stressing that 3 argument main should be treated as nothing more than a
historical curiosity now.

Lawrence

[Villy Kruse]

On Wed, 23 Feb 2005 12:25:53 +0000,
Lawrence Kirby <lk****@netactive.co.uk> wrote:

On Wed, 23 Feb 2005 09:08:30 +0000, infobahn wrote:

Villy Kruse wrote:

On Tue, 22 Feb 2005 08:38:40 -0700,
Alan Balmer <al******@att.net> wrote:

> If you know the name of the environment variable you're looking for,
> yes, it's easier to use getenv(). If, for some reason, you wanted to
> search the environment variables, the "char *env[]" form would be the
> way to do it.
>

If you realy want to do that then use the global variable environ.

Not if you want your code to stay portable.

Using either method (environ or 3 argument main) makes your code
non-portable as far as standard C is concerned. extern char **environ is
at least defined by POSIX and as such would have to be considered more
portable. Using the 3 argument form of main() will probably compile and
link successfully on more platforms, it just means that where it isn't
supported it misbehaves at runtime rather than fails to compile, which is
worse.

I was trying to point out that even on systems where it actualy does
work it may stop working for no appearent reason. That means that even
in cases where porting is not an issue, and even if some test programs
has proven it works on a particular system, using the third argument to
main may fail.

Villy

[infobahn]

Lawrence Kirby wrote:

On Wed, 23 Feb 2005 09:08:30 +0000, infobahn wrote:

Villy Kruse wrote:

On Tue, 22 Feb 2005 08:38:40 -0700,
Alan Balmer <al******@att.net> wrote:

> If you know the name of the environment variable you're looking for,
> yes, it's easier to use getenv(). If, for some reason, you wanted to
> search the environment variables, the "char *env[]" form would be the
> way to do it.
>

If you realy want to do that then use the global variable environ.
Not if you want your code to stay portable.

Using either method (environ or 3 argument main) makes your code
non-portable as far as standard C is concerned.

Yes, precisely.
extern char **environ is
at least defined by POSIX and as such would have to be considered more
portable.

More portable, but not maximally portable. environ doesn't provide
to an otherwise portable program anything that getenv() can't provide
portably; that is, if the program needs to enquire the environment,
getenv() is perfectly adequate to the task, and doesn't rely on
the existence of environ.
<snipped good stuff that I agree with>

[Dave Vandervies]

In article <42***************@btinternet.com>,
infobahn <in******@btinternet.com> wrote:

Lawrence Kirby wrote:

extern char **environ is
at least defined by POSIX and as such would have to be considered more
portable.

More portable, but not maximally portable. environ doesn't provide
to an otherwise portable program anything that getenv() can't provide
portably; that is, if the program needs to enquire the environment,
getenv() is perfectly adequate to the task, and doesn't rely on
the existence of environ.

If a program wants to make a list of all the environment variables that
are defined, can it do so using getenv() and still finish before the
heat death of the universe?
dave

--
Dave Vandervies dj******@csclub.uwaterloo.ca
Fortunately programmers who actually use those anomalous cases are few,
and getting fewer every time we catch up to one.
--David Thompson in comp.lang.c

[infobahn]

Dave Vandervies wrote:

In article <42***************@btinternet.com>,
infobahn <in******@btinternet.com> wrote:

[...]if the program needs to enquire the environment,
getenv() is perfectly adequate to the task, and doesn't rely on
the existence of environ.

If a program wants to make a list of all the environment variables that
are defined, can it do so using getenv() and still finish before the
heat death of the universe?

Sure. Just run it on a quantum computer. :-)

[Alan Balmer]

On Wed, 23 Feb 2005 12:25:53 +0000, Lawrence Kirby
<lk****@netactive.co.uk> wrote:

extern char **environ is
at least defined by POSIX and as such would have to be considered more
portable.

I'm glad you mentioned that - I hadn't realized it was defined by
POSIX (though I've now looked it up :-). I'll remember that just in
case I ever need to use it. (Which seems unlikely, actually.)

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