parsing practice

R

Rui Maciel

Bill said:
I'm not quite understanding here. "Nonzero is not good enough." If there
are no argc's I want the program to terminate with the "usage error"
error. As long as it is nonzero I am happy. I'm stuck on this one.

The OS always passes at least one argument, the program's name, which is available through
argv[0]. The following parameters, if any were passed, will be available in argv[1],
argv[2],...

On a side note, if I'm not mistaken it's possible that the OS may pass a NULL instead of a
string containing the program's name. Nonetheless, argv[0] is always reserved for that task
and the remaining parameters will always be passed from argv[1] forward.


Rui Maciel
 
S

Seebs

argc is guaranteed to be greater than zero, as argv indicates the number of parameters
which were passed. As argv[0] is used to point to the program's name, it will always be at
least 1. Therefore, this test is always false...

Not so. It is possible (though unusual) to have argc be zero, and
argv[0] to be null.

It's not COMMON, but there's nothing prohibiting it.

-s
 
O

osmium

Seebs wrote:\
argc is guaranteed to be greater than zero, as argv indicates the
number of parameters which were passed. As argv[0] is used to point
to the program's name, it will always be at least 1. Therefore, this
test is always false...

Not so. It is possible (though unusual) to have argc be zero, and
argv[0] to be null.

It's not COMMON, but there's nothing prohibiting it.

Since the word null has several meanings I can't convert your comment into
something that makes sense to me. For those of us who do not get warm
tingly feelings from reading the standard, how about quoting the relevant
parts?

I would think that if argc went to 0, argv would not exist. And the
standard couldn't even mention argv and the contents of the first cell in
that array.
 
W

Willem

osmium wrote:
) Seebs wrote:\
)> Not so. It is possible (though unusual) to have argc be zero, and
)> argv[0] to be null.
)>
)> It's not COMMON, but there's nothing prohibiting it.
)
) Since the word null has several meanings I can't convert your comment into
) something that makes sense to me. For those of us who do not get warm
) tingly feelings from reading the standard, how about quoting the relevant
) parts?
)
) I would think that if argc went to 0, argv would not exist. And the
) standard couldn't even mention argv and the contents of the first cell in
) that array.

AFAIK, argv[argc] == NULL

In other words, argv[] is an array with argc+1 elements,
the last of which is NULL. A NULL-terminated list, iow.

I'm sure somebody will come along with the relevant parts of the standard.


SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT
 
S

Seebs

Since the word null has several meanings I can't convert your comment into
something that makes sense to me. For those of us who do not get warm
tingly feelings from reading the standard, how about quoting the relevant
parts?

Don't have them to hand. :)
I would think that if argc went to 0, argv would not exist. And the
standard couldn't even mention argv and the contents of the first cell in
that array.

argv HAS to exist. It is a pointer to at least argc+1 pointers, the last of
which is a null pointer.

So if argc is 0, then argv[0] == NULL.

Similarly, if argc is 1, then argv[0] is not null, and argv[1] is null.

-s
 
B

Ben Bacarisse

osmium said:
Seebs wrote:\
argc is guaranteed to be greater than zero, as argv indicates the
number of parameters which were passed. As argv[0] is used to point
to the program's name, it will always be at least 1. Therefore, this
test is always false...

Not so. It is possible (though unusual) to have argc be zero, and
argv[0] to be null.

It's not COMMON, but there's nothing prohibiting it.

Since the word null has several meanings I can't convert your comment into
something that makes sense to me. For those of us who do not get warm
tingly feelings from reading the standard, how about quoting the relevant
parts?

The main bits are:

5.1.2.2.1 Program startup

2 If they are declared, the parameters to the main function shall
obey the following constraints:

-- The value of argc shall be nonnegative.
-- argv[argc] shall be a null pointer.

Further bullet points explain what must be the case when argc > 0.
I would think that if argc went to 0, argv would not exist. And the
standard couldn't even mention argv and the contents of the first cell in
that array.

argc is not the size of the argv array (technically the array pointed
to by argv). Instead, argc == 0 implies that there is (at least) one
element to the array -- a null pointer.
 
O

osmium

Ben said:
osmium said:
Seebs wrote:\
argc is guaranteed to be greater than zero, as argv indicates the
number of parameters which were passed. As argv[0] is used to
point to the program's name, it will always be at least 1.
Therefore, this test is always false...

Not so. It is possible (though unusual) to have argc be zero, and
argv[0] to be null.

It's not COMMON, but there's nothing prohibiting it.

Since the word null has several meanings I can't convert your
comment into something that makes sense to me. For those of us who
do not get warm tingly feelings from reading the standard, how about
quoting the relevant parts?

The main bits are:

5.1.2.2.1 Program startup

2 If they are declared, the parameters to the main function shall
obey the following constraints:

-- The value of argc shall be nonnegative.
-- argv[argc] shall be a null pointer.

Further bullet points explain what must be the case when argc > 0.
I would think that if argc went to 0, argv would not exist. And the
standard couldn't even mention argv and the contents of the first
cell in that array.

argc is not the size of the argv array (technically the array pointed
to by argv). Instead, argc == 0 implies that there is (at least) one
element to the array -- a null pointer.

I guess my mistake was making a WAG that c in argc stood for count. Or
something like that. My interest level in the standard has returned to its
normal, very low, level. Thanks guys, all of you.
 
L

Lew Pitcher

Ben said:
osmium said:
Seebs wrote:\

argc is guaranteed to be greater than zero, as argv indicates the
number of parameters which were passed. As argv[0] is used to
point to the program's name, it will always be at least 1.
Therefore, this test is always false...

Not so. It is possible (though unusual) to have argc be zero, and
argv[0] to be null.

It's not COMMON, but there's nothing prohibiting it.

Since the word null has several meanings I can't convert your
comment into something that makes sense to me. For those of us who
do not get warm tingly feelings from reading the standard, how about
quoting the relevant parts?

The main bits are:

5.1.2.2.1 Program startup

2 If they are declared, the parameters to the main function shall
obey the following constraints:

-- The value of argc shall be nonnegative.
-- argv[argc] shall be a null pointer.

Further bullet points explain what must be the case when argc > 0.
I would think that if argc went to 0, argv would not exist. And the
standard couldn't even mention argv and the contents of the first
cell in that array.

argc is not the size of the argv array (technically the array pointed
to by argv). Instead, argc == 0 implies that there is (at least) one
element to the array -- a null pointer.

I guess my mistake was making a WAG that c in argc stood for count. Or
something like that.

At one time, it did. Times have changed, though, and the standardization of
the C language subtly changed the meaning of "argc" to what it is now in
the standard.

FWIW, here's the relevant part of the "original" standard (K&R v1)

5.11 Command-line Arguments

In environments that support C, there is a way to pass command-line
arguments or parameters to a program when it begins executing. When
main is called to begin execution, it is called with two arguments. The
the first (conventionally called argc) is the number of command-line
arguments the program was invoked with; the second (argv) is a pointer to
an array of character strings that contain the arguments, one per string.

("The C Programming Language" by Brian W. Kernighan and Dennis M. Ritchie,
Copyright (c) 1978 by Bell Telephone Laboratories, Incorporated,
Published by Prentice-Hall, Inc., Englewood Cliffs, New Jersey 07632)
 
B

Ben Bacarisse

osmium said:
Ben said:
osmium said:
Seebs wrote:\

argc is guaranteed to be greater than zero, as argv indicates the
number of parameters which were passed. As argv[0] is used to
point to the program's name, it will always be at least 1.
Therefore, this test is always false...

Not so. It is possible (though unusual) to have argc be zero, and
argv[0] to be null.

It's not COMMON, but there's nothing prohibiting it.

Since the word null has several meanings I can't convert your
comment into something that makes sense to me. For those of us who
do not get warm tingly feelings from reading the standard, how about
quoting the relevant parts?

The main bits are:

5.1.2.2.1 Program startup

2 If they are declared, the parameters to the main function shall
obey the following constraints

-- The value of argc shall be nonnegative.
-- argv[argc] shall be a null pointer.

Further bullet points explain what must be the case when argc > 0.
I would think that if argc went to 0, argv would not exist. And the
standard couldn't even mention argv and the contents of the first
cell in that array.

argc is not the size of the argv array (technically the array pointed
to by argv). Instead, argc == 0 implies that there is (at least) one
element to the array -- a null pointer.

I guess my mistake was making a WAG that c in argc stood for count. Or
something like that.

I think the 'c' can still be considered a count. argv is terminated
with a null pointer but I wouldn't expect such a sentinel to be
included in the count. Looked at this way, argc is still a count but
the smallest permissible argv has one (null) element.

<snip>
 
R

Rui Maciel

Seebs said:
Not so. It is possible (though unusual) to have argc be zero, and
argv[0] to be null.

It's not COMMON, but there's nothing prohibiting it.

You are right. The argc parameter must be nonnegative, argv[argc] must be a null pointer and
if argc is greater than zero then argv[0] must represent the program's name. So it appears
that the standard accepts two options for the scenario where no parameter is passed to the
program. Those scenarios are:

a) without parameters: argc == 0, argv[0] == NULL
with n parameters: argc == n+1, argv[0] == NULL, argv[argc] == NULL

b) without parameters: argc == 1, argv[0] == <program name>, argv[1] == NULL
with n parameters: argc == n+1, argv[0] == <program name>, argv[arg] == NULL

....with <program name> being either NULL or a string storing the program's name.

In other words, if any parameter is passed to main() then argv[0] is reserved for the
program's name and all parameters must be available from argv[1] forward.

This means the a) scenario is a bit weird. It means that, in the implementations that follow
it, argc may be either 0 or 2 and argv[0] may never point anywhere besides a NULL. This way
of doing things is a bit non-linear. Does anyone know of any platform which works this way?


Rui Maciel
 
B

Ben Bacarisse

Rui Maciel said:
Seebs said:
Not so. It is possible (though unusual) to have argc be zero, and
argv[0] to be null.

It's not COMMON, but there's nothing prohibiting it.

You are right. The argc parameter must be nonnegative, argv[argc]
must be a null pointer and if argc is greater than zero then argv[0]
must represent the program's name. So it appears that the standard
accepts two options for the scenario where no parameter is passed to
the program. Those scenarios are:

a) without parameters: argc == 0, argv[0] == NULL with n parameters:
argc == n+1, argv[0] == NULL, argv[argc] == NULL

b) without parameters: argc == 1, argv[0] == <program name>, argv[1]
== NULL with n parameters: argc == n+1, argv[0] == <program name>,
argv[arg] == NULL

...with <program name> being either NULL or a string storing the
program's name.

That's not quite right. The standard says:

"If the value of argc is greater than zero, the string pointed to by
argv[0] represents the program name; argv[0][0] shall be the null
character if the program name is not available from the host
environment."

so there is no permission for argv[1] to be NULL when argc == 1.
argv[1] can be an empty string, but that's as bad as it gets. A
previous paragraph includes:

"If the value of argc is greater than zero, the array members
argv[0] through argv[argc-1] inclusive shall contain pointers to
strings, [...]"

so again, there is no permission for any of the argv elements (except
argv[argc]) to be NULL since NULL is not a "pointer to a string".
In other words, if any parameter is passed to main() then argv[0] is
reserved for the program's name and all parameters must be available
from argv[1] forward.

This means the a) scenario is a bit weird. It means that, in the
implementations that follow it, argc may be either 0 or 2 and argv[0]
may never point anywhere besides a NULL.

I don't see how you get these two scenarios. argc can be 0, 1, 2
whatever and none of the argv other than argv[argc] can be NULL.
There *is* a special case when argc == 0 because then there is no
further information available, but that's not a different scenario,
just a single degenerate case.

<snip>
 
E

Ersek, Laszlo

argc is guaranteed to be greater than zero, as argv indicates the number of parameters
which were passed. As argv[0] is used to point to the program's name, it will always be at
least 1. Therefore, this test is always false...

Not so. It is possible (though unusual) to have argc be zero, and
argv[0] to be null.

It's not COMMON, but there's nothing prohibiting it.

Actually, there is, at least in the SUS, versions 1 to 4. They all
contain the following sentence verbatim for exec() and co.:

"The arguments represented by arg0, ... are pointers to null-terminated
character strings."

lacos
 
M

Mark Hobley

Rui Maciel said:
This means the a) scenario is a bit weird. It means that, in the
implementations that follow it, argc may be either 0 or 2 and argv[0] may
never point anywhere besides a NULL. This way of doing things is a bit
non-linear. Does anyone know of any platform which works this way?

I'm not sure. I know that MSDOS does not provide the program name in the
command line arguments, but I never looked at how a C compiler handled that.

Mark.
 
C

Coos Haak

Op Sun, 14 Mar 2010 10:08:02 GMT schreef Mark Hobley:
Rui Maciel said:
This means the a) scenario is a bit weird. It means that, in the
implementations that follow it, argc may be either 0 or 2 and argv[0] may
never point anywhere besides a NULL. This way of doing things is a bit
non-linear. Does anyone know of any platform which works this way?

I'm not sure. I know that MSDOS does not provide the program name in the
command line arguments, but I never looked at how a C compiler handled that.

Mark.

MS-DOS puts the path and name of the program after the environment
strings.
TCC returns it in argv[0] as expected.
 
R

Rui Maciel

Ben said:
That's not quite right. The standard says:

"If the value of argc is greater than zero, the string pointed to by
argv[0] represents the program name; argv[0][0] shall be the null
character if the program name is not available from the host
environment."

so there is no permission for argv[1] to be NULL when argc == 1.

I don't believe that is true. The standard says in 5.1.2.2.1:

— argv[argc] shall be a null pointer.

So if argc == 1 then argv[1] must be a null pointer.



In other words, if any parameter is passed to main() then argv[0] is
reserved for the program's name and all parameters must be available
from argv[1] forward.

This means the a) scenario is a bit weird. It means that, in the
implementations that follow it, argc may be either 0 or 2 and argv[0]
may never point anywhere besides a NULL.

I don't see how you get these two scenarios. argc can be 0, 1, 2
whatever and none of the argv other than argv[argc] can be NULL.
There *is* a special case when argc == 0 because then there is no
further information available, but that's not a different scenario,
just a single degenerate case.

Silly me. I've mindlessly read "null character" as being "null pointer". Shameful.


Rui Maciel
 
B

Ben Bacarisse

Rui Maciel said:
Ben said:
That's not quite right. The standard says:

"If the value of argc is greater than zero, the string pointed to by
argv[0] represents the program name; argv[0][0] shall be the null
character if the program name is not available from the host
environment."

so there is no permission for argv[1] to be NULL when argc == 1.

I don't believe that is true. The standard says in 5.1.2.2.1:

— argv[argc] shall be a null pointer.

So if argc == 1 then argv[1] must be a null pointer.

Yes, that was a typo. I was responding to your scenario (a) where you
seemed to suggest that argv[0] could be NULL when argc == 1. I meant
to type: there is no permission for argv[0] to be NULL when argc == 1.

In other words, if any parameter is passed to main() then argv[0] is
reserved for the program's name and all parameters must be available
from argv[1] forward.

This means the a) scenario is a bit weird. It means that, in the
implementations that follow it, argc may be either 0 or 2 and argv[0]
may never point anywhere besides a NULL.

I don't see how you get these two scenarios. argc can be 0, 1, 2
whatever and none of the argv other than argv[argc] can be NULL.
There *is* a special case when argc == 0 because then there is no
further information available, but that's not a different scenario,
just a single degenerate case.

Silly me. I've mindlessly read "null character" as being "null
pointer". Shameful.

Ah, well, in that case the whole thing is irrelevant now. If I had
not mistyped it would all have been resolved by now!
 
R

Rui Maciel

Ben Bacarisse wrote:

Ah, well, in that case the whole thing is irrelevant now. If I had
not mistyped it would all have been resolved by now!

Damn keyboards. It's a conspiracy, I say.


Rui Maciel
 
R

Richard Bos

Rui Maciel said:
Bill said:
I'm not quite understanding here. "Nonzero is not good enough." If there
are no argc's I want the program to terminate with the "usage error"
error. As long as it is nonzero I am happy. I'm stuck on this one.

The OS always passes at least one argument, the program's name, which is available through
argv[0]. The following parameters, if any were passed, will be available in argv[1],
argv[2],...

On a side note, if I'm not mistaken it's possible that the OS may pass a NULL instead of a
string containing the program's name.

Not only is this allowable, in such a case argc must be 0 as well.
However, it's also possible for there to be arguments, but argv[0] to
contain an empty string, or some other useless "approximation" of one or
more of the names the program has.

Richard
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
474,432
Messages
2,571,680
Members
48,796
Latest member
Greg L.

Latest Threads

Top