Spot the error...

[NwsGrp1]

A colleague is reading through some C articles and was asked if there
are any errors in the following code. Neither of us can spot any
issues, I have compiled it with VC8 and GCC at their strictest
settings and got nothing of note.

Here is the code:

#include <stdio.h>

void usage(char *ptCommand);

int main(int argc, char * argv[]) {
if (argc < 2)
usage(argv[0]);

return 0;
}

void usage(char *ptCommand) {
char usageInfo[1023];

_snprintf(usageInfo, 1023, "Usage: %s \n", ptCommand);

printf(usageInfo);
}

Thank you.

[Ian Collins]

NwsGrp1 wrote:

A colleague is reading through some C articles and was asked if there
are any errors in the following code. Neither of us can spot any
issues, I have compiled it with VC8 and GCC at their strictest
settings and got nothing of note.

Here is the code:

#include <stdio.h>

void usage(char *ptCommand);

int main(int argc, char * argv[]) {
if (argc < 2)
usage(argv[0]);

return 0;
}

void usage(char *ptCommand) {
char usageInfo[1023];

_snprintf(usageInfo, 1023, "Usage: %s \n", ptCommand);

There isn't a function called _snprintf in standard C.

--
Ian Collins.

[Bavo]

NwsGrp1 wrote on 20/03/2007 11:44:

A colleague is reading through some C articles and was asked if there
are any errors in the following code. Neither of us can spot any
issues, I have compiled it with VC8 and GCC at their strictest
settings and got nothing of note.

Here is the code:

#include <stdio.h>

void usage(char *ptCommand);

int main(int argc, char * argv[]) {
if (argc < 2)
usage(argv[0]);

return 0;
}

void usage(char *ptCommand) {
char usageInfo[1023];

_snprintf(usageInfo, 1023, "Usage: %s \n", ptCommand);

printf(usageInfo);
}

Thank you.

Use
printf("%s", usageInfo)
in case ptCommand contains format specifiers.

Bavo

[Beej Jorgensen]

NwsGrp1 <nw*****@googlemail.comwrote:

_snprintf(usageInfo, 1023, "Usage: %s \n", ptCommand);

(I don't have _snprintf(), but do have snprintf(). I say... 4 people
are about to call you on this one. :)

As for "errors", check this out: I named the executable "foo%s" and it
crashed when I ran it. Why?

-Beej

[NwsGrp1]

On Mar 20, 11:10 am, Ian Collins <[e-mail]:

NwsGrp1 wrote:

A colleague is reading through some C articles and was asked if there
are any errors in the following code. Neither of us can spot any
issues, I have compiled it with VC8 and GCC at their strictest
settings and got nothing of note.

[snip]

_snprintf(usageInfo, 1023, "Usage: %s \n", ptCommand);

There isn't a function called _snprintf in standard C.

Apologies I meant snprintf mentioned in section 7.19.6.5 in n1124.

Carl.

[Richard Heathfield]

NwsGrp1 said:

A colleague is reading through some C articles and was asked if there
are any errors in the following code. Neither of us can spot any
issues, I have compiled it with VC8 and GCC at their strictest
settings and got nothing of note.

Here is the code:

#include <stdio.h>

void usage(char *ptCommand);

int main(int argc, char * argv[]) {
if (argc < 2)
usage(argv[0]);

I have read Ian's remark on _snprintf, which is correct. I have a couple
of other remarks to make in addition.

Firstly, the Standard allows argc to be 0, in which case argv[0] will be
NULL, in which case your usage function has problems.

>
return 0;
}

void usage(char *ptCommand) {

You might want to make this const char * rather than char *.

char usageInfo[1023];

_snprintf(usageInfo, 1023, "Usage: %s \n", ptCommand);

printf(usageInfo);

Why are you bothering with the string? If you want to restrict the total
length of the output to 1023, why not just write this...

printf("Usage: %.1013s \n", ptCommand);

Incidentally, if they obey this usage instruction, all they'll get is
the usage instruction again. :-)

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

[NwsGrp1]

On Mar 20, 11:19 am, Beej Jorgensen <[e-mail]:

NwsGrp1 <[e-mail]:

_snprintf(usageInfo, 1023, "Usage: %s \n", ptCommand);

[snip]
As for "errors", check this out: I named the executable "foo%s" and it
crashed when I ran it. Why?

-Beej

Damn... format string vulnerability. I looked for that in the snprintf
line but not the printf, I was fooled into thinking it was safe after
the snprintf and never thought of actually testing it with something
like "foo%n%n%n".

Thank you Beej, Bavo, all.

Carl.

[Gregor H.]

On Tue, 20 Mar 2007 11:23:01 +0000, Richard Heathfield
<rj*@see.sig.invalidwrote:

>
Firstly, the Standard allows argc to be 0, in which case argv[0] will be
NULL, in which case your usage function has problems.

Can you imagine a (real) case where this actually might occur? (I'm just
curios).

K&R are less "pedantic" concerning this point than you are. They write in
K&R2, p. 115:

"By convention, argv[0] is the name by which the program
was invoked, so argc is at least 1."

If your claim is true, this claim of K&R is in contradiction to the
standard, right? (Or is this something where ANSI-C and C99 do differ?)
G. H.

--

E-mail: info<at>simple-line<Punkt>de

[Richard Heathfield]

Gregor H. said:

On Tue, 20 Mar 2007 11:23:01 +0000, Richard Heathfield
<rj*@see.sig.invalidwrote:

>>
Firstly, the Standard allows argc to be 0, in which case argv[0] will
be NULL, in which case your usage function has problems.

Can you imagine a (real) case where this actually might occur? (I'm
just curios).

I have never owned a Mac, and the last time I used one (that I can
recall) is before I began programming in C, but I am given to
understand that some Mac-based implementations do set argc to 0 and
argv to NULL. I may be mistaken in this regard.

>
K&R are less "pedantic" concerning this point than you are. They write
in K&R2, p. 115:

"By convention, argv[0] is the name by which the program
was invoked, so argc is at least 1."

If your claim is true, this claim of K&R is in contradiction to the
standard, right?

Right. I once considered telling dmr about this, but I kept forgetting.
:-)

(Or is this something where ANSI-C and C99 do differ?)

Nope.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

[user923005]

On Mar 20, 3:44 am, "NwsGrp1" <[e-mail]:

A colleague is reading through some C articles and was asked if there
are any errors in the following code. Neither of us can spot any
issues, I have compiled it with VC8 and GCC at their strictest
settings and got nothing of note.

Here is the code:

#include <stdio.h>

void usage(char *ptCommand);

int main(int argc, char * argv[]) {
if (argc < 2)
usage(argv[0]);

return 0;

}

void usage(char *ptCommand) {
char usageInfo[1023];

_snprintf(usageInfo, 1023, "Usage: %s \n", ptCommand);

printf(usageInfo);

}

Thank you.

The errors spotted by the others are diagnosed by splint in a fraction
of a second. Also, usage() seems a logical choice for static, since
the end-user should not be calling it.

C:\tmp>splint foo.c
Splint 3.1.1 --- 12 Mar 2007

foo.c: (in function usage)
foo.c(16,3): Unrecognized identifier: _snprintf
Identifier used in code has not been declared. (Use -unrecog to
inhibit
warning)
foo.c(18,2): Format string parameter to printf is not a compile-time
constant:
usageInfo
Format parameter is not known at compile-time. This can lead to
security
vulnerabilities because the arguments cannot be type checked. (Use
-formatconst to inhibit warning)
foo.c(3,6): Function exported but not used outside foo: usage
A declaration is exported, but not used outside this module.
Declaration can
use static qualifier. (Use -exportlocal to inhibit warning)
foo.c(20,1): Definition of usage

Finished checking --- 3 code warnings

C:\tmp>

[Keith Thompson]

Gregor H. <nomail@invalidwrites:
[...]

If your claim is true, this claim of K&R is in contradiction to the
standard, right? (Or is this something where ANSI-C and C99 do differ?)

ANSI C and C99 don't differ at all; ANSI has adopted the 1999 ISO C
standard as an ANSI standard.

Yes, we know what you meant; the phrase "ANSI C" usually refers to the
language defined by the 1989 ANSI standard and the 1990 ISO standard.
But, strictly speaking, it's incorrect. I suggest avoiding ambiguity
by referring to "C89" or "C90" (they're the same language) or "C99".

--
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."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Flash Gordon]

Richard Heathfield wrote, On 20/03/07 16:14:

Gregor H. said:

>On Tue, 20 Mar 2007 11:23:01 +0000, Richard Heathfield
<rj*@see.sig.invalidwrote:

>>Firstly, the Standard allows argc to be 0, in which case argv[0] will
be NULL, in which case your usage function has problems.

Can you imagine a (real) case where this actually might occur? (I'm
just curios).

I have never owned a Mac, and the last time I used one (that I can
recall) is before I began programming in C, but I am given to
understand that some Mac-based implementations do set argc to 0 and
argv to NULL. I may be mistaken in this regard.

Also in Unix when using the non-standard exec* functions to invoke a
program you get to specify what you want the entire argument list to be,
including argv[0]. If you specify an empty list then that is what will
be passed to the program and argc will be 0. So yes, on Unix your
program really *can* be run with argc==0, although the mechanics of how
you achieve this are off topic here.

>K&R are less "pedantic" concerning this point than you are. They write
in K&R2, p. 115:

"By convention, argv[0] is the name by which the program
was invoked, so argc is at least 1."

If your claim is true, this claim of K&R is in contradiction to the
standard, right?

Right. I once considered telling dmr about this, but I kept forgetting.
:-)

If the "by convention" is considered to apply to the minimum value of
argc as well as the value of argv[0] then it is true, and I would think
this is what was intended by that sentence.
--
Flash Gordon

[Gregor H.]

On Tue, 20 Mar 2007 12:38:49 -0700, Keith Thompson <ks***@mib.orgwrote:

>>
If your claim is true, this claim of K&R is in contradiction to the
standard, right? (Or is this something where ANSI-C and C99 do differ?)

ANSI C and C99 don't differ at all; ANSI has adopted the 1999 ISO C
standard as an ANSI standard.

Yes, we know what you meant.

We? You are many?

Well, at least *I* know what I mean, and it seems you know it too. :-)

We (obviously) mean

>
"C89" or "C90"

here.
G. H.

--

E-mail: info<at>simple-line<Punkt>de

[Gregor H.]

On Tue, 20 Mar 2007 19:57:45 +0000, Flash Gordon <sp**@flash-gordon.me.uk>
wrote:

>>>>
Firstly, the Standard allows argc to be 0, in which case argv[0] will
be NULL, in which case your usage function has problems.

Can you imagine a (real) case where this actually might occur? (I'm
just curios).

I have never owned a Mac, and the last time I used one (that I can
recall) is before I began programming in C, but I am given to
understand that some Mac-based implementations do set argc to 0 and
argv to NULL. I may be mistaken in this regard.

Also in Unix when using the non-standard exec* functions to invoke a
program you get to specify what you want the entire argument list to be,
including argv[0]. If you specify an empty list then that is what will
be passed to the program and argc will be 0. So yes, on Unix your
program really *can* be run with argc==0, although the mechanics of how
you achieve this are off topic here.

So one really has to take this possibility into account, I guess. (?)

>>>
K&R are less "pedantic" concerning this point than you are. They write
in K&R2, p. 115:

"By convention, argv[0] is the name by which the program
was invoked, so argc is at least 1."

If your claim is true, this claim of K&R is in contradiction to the
standard, right?

Right. I once considered telling dmr about this, but I kept forgetting.
:-)

If the "by convention" is considered to apply to the minimum value of
argc as well as the value of argv[0] then it is true, and I would think
this is what was intended by that sentence.

Sorry, I didn't get that. Could you elaborate on that. (I'm just curious.)
G. H.

--

E-mail: info<at>simple-line<Punkt>de

[Randy Howard]

On Tue, 20 Mar 2007 06:27:56 -0500, NwsGrp1 wrote
(in article <11**********************@y80g2000hsf.googlegroups .com>):

On Mar 20, 11:19 am, Beej Jorgensen <[e-mail]:

>NwsGrp1 <[e-mail]:

>>_snprintf(usageInfo, 1023, "Usage: %s \n", ptCommand);

[snip]
As for "errors", check this out: I named the executable "foo%s" and it
crashed when I ran it. Why?

-Beej

Damn... format string vulnerability. I looked for that in the snprintf
line but not the printf, I was fooled into thinking it was safe after
the snprintf and never thought of actually testing it with something
like "foo%n%n%n".

It's disappointing just how many supposedly professionally written
programs will crap out if you feed format specifiers to it as input.


--
Randy Howard (2reply remove FOOBAR)
"The power of accurate observation is called cynicism by those
who have not got it." - George Bernard Shaw

[Randy Howard]

On Tue, 20 Mar 2007 11:14:01 -0500, Richard Heathfield wrote
(in article <qa******************************@bt.com>):

Gregor H. said:

>On Tue, 20 Mar 2007 11:23:01 +0000, Richard Heathfield
<rj*@see.sig.invalidwrote:

>>>
Firstly, the Standard allows argc to be 0, in which case argv[0] will
be NULL, in which case your usage function has problems.

Can you imagine a (real) case where this actually might occur? (I'm
just curios).

I have never owned a Mac, and the last time I used one (that I can
recall) is before I began programming in C, but I am given to
understand that some Mac-based implementations do set argc to 0 and
argv to NULL. I may be mistaken in this regard.

That might have been true in early Mac OS platforms before OS X came
along, I don't have one to try, but OS X, which is basically a properly
built and working Linux distro with a nicer GUI than most, behaves just
as you would expect it to.

--
Randy Howard (2reply remove FOOBAR)
"The power of accurate observation is called cynicism by those
who have not got it." - George Bernard Shaw

[Ian Collins]

Randy Howard wrote:

On Tue, 20 Mar 2007 11:14:01 -0500, Richard Heathfield wrote

>>
I have never owned a Mac, and the last time I used one (that I can
recall) is before I began programming in C, but I am given to
understand that some Mac-based implementations do set argc to 0 and
argv to NULL. I may be mistaken in this regard.

That might have been true in early Mac OS platforms before OS X came
along, I don't have one to try, but OS X, which is basically a properly
built and working Linux distro with a nicer GUI than most, behaves just
as you would expect it to.

<OT>Nonsense, OS-X is based on BSD</OT>

--
Ian Collins.

[Keith Thompson]

Gregor H. <nomail@invalidwrites:

On Tue, 20 Mar 2007 12:38:49 -0700, Keith Thompson <ks***@mib.orgwrote:

>>If your claim is true, this claim of K&R is in contradiction to the
standard, right? (Or is this something where ANSI-C and C99 do differ?)

ANSI C and C99 don't differ at all; ANSI has adopted the 1999 ISO C
standard as an ANSI standard.

Yes, we know what you meant.

We? You are many?

Yes, we (I and the other readers of this newsgroup) are many.

Well, at least *I* know what I mean, and it seems you know it too. :-)

Yes, because I'm familiar with the widespread error of referring to
C89 as "ANSI C".

We (obviously) mean

>>
"C89" or "C90"

here.

If you use the term "ANSI C", most people will know that you mean
C89/C90, but some will insist that the term refers to the standard
currently recognized by ANSI, namely C99.

If you use the term "C89" or "C90" (or "C99"), everyone will know
exactly what you mean. It's even less typing.

I'm simply recommending that you use the term "C89", "C90", or "C99"
rather than "ANSI C", because doing so is more correct, less
ambiguous, and shorter. You can, of course, do whatever you like, but
frankly I can't think of any reason not to follow my advice (not
because it's from me, but just because it's good advice).

--
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."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Keith Thompson]

Randy Howard <ra*********@FOOverizonBAR.netwrites:
[...]

That might have been true in early Mac OS platforms before OS X came
along, I don't have one to try, but OS X, which is basically a properly
built and working Linux distro with a nicer GUI than most, behaves just
as you would expect it to.

<WAY_OT>
Mac OS X doesn't use the Linux kernel, so it's not a "Linux distro",
though it does have some similarities.
</WAY_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."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Randy Howard]

On Tue, 20 Mar 2007 16:27:47 -0500, Ian Collins wrote
(in article <56*************@mid.individual.net>):

Randy Howard wrote:

>On Tue, 20 Mar 2007 11:14:01 -0500, Richard Heathfield wrote

>>>
I have never owned a Mac, and the last time I used one (that I can
recall) is before I began programming in C, but I am given to
understand that some Mac-based implementations do set argc to 0 and
argv to NULL. I may be mistaken in this regard.

That might have been true in early Mac OS platforms before OS X came
along, I don't have one to try, but OS X, which is basically a properly
built and working Linux distro with a nicer GUI than most, behaves just
as you would expect it to.

<OT>Nonsense, OS-X is based on BSD</OT>

I didn't mean genetically. Obviously OS X is not running a Linux
kernel, etc.

I was referring to its behavior. It's what I wanted Linux to be for
over a decade before I gave up on it ever arriving.

--
Randy Howard (2reply remove FOOBAR)
"The power of accurate observation is called cynicism by those
who have not got it." - George Bernard Shaw

[Flash Gordon]

Gregor H. wrote, On 20/03/07 20:36:

On Tue, 20 Mar 2007 19:57:45 +0000, Flash Gordon <sp**@flash-gordon.me.uk>
wrote:

>>>>Firstly, the Standard allows argc to be 0, in which case argv[0] will
be NULL, in which case your usage function has problems.
>
Can you imagine a (real) case where this actually might occur? (I'm
just curios).

I have never owned a Mac, and the last time I used one (that I can
recall) is before I began programming in C, but I am given to
understand that some Mac-based implementations do set argc to 0 and
argv to NULL. I may be mistaken in this regard.

Also in Unix when using the non-standard exec* functions to invoke a
program you get to specify what you want the entire argument list to be,
including argv[0]. If you specify an empty list then that is what will
be passed to the program and argc will be 0. So yes, on Unix your
program really *can* be run with argc==0, although the mechanics of how
you achieve this are off topic here.

So one really has to take this possibility into account, I guess. (?)

You definitely should.

>>>K&R are less "pedantic" concerning this point than you are. They write
in K&R2, p. 115:

"By convention, argv[0] is the name by which the program
was invoked, so argc is at least 1."

If your claim is true, this claim of K&R is in contradiction to the
standard, right?

Right. I once considered telling dmr about this, but I kept forgetting.
:-)

If the "by convention" is considered to apply to the minimum value of
argc as well as the value of argv[0] then it is true, and I would think
this is what was intended by that sentence.

Sorry, I didn't get that. Could you elaborate on that. (I'm just curious.)

I believe that what was written can be read as:
(A) By convention argv[0] is the name by which the program was invoked.
(B) By convention argc is at least 1 due to (A).

This is true, since it is the convention. However, as it is only a
convention there are times when it does not happen.
--
Flash Gordon

[Gregor H.]

On Tue, 20 Mar 2007 21:13:52 GMT, Randy Howard
<ra*********@FOOverizonBAR.netwrote:

>>>>
Firstly, the Standard allows argc to be 0, in which case argv[0] will
be NULL, in which case your usage function has problems.

Can you imagine a (real) case where this actually might occur? (I'm
just curios).

I have never owned a Mac, and the last time I used one (that I can
recall) is before I began programming in C, but I am given to
understand that some Mac-based implementations do set argc to 0 and
argv to NULL. I may be mistaken in this regard.

That might have been true in early Mac OS platforms before OS X came
along, I don't have one to try, but OS X, which is basically a properly
built and working Linux distro with a nicer GUI than most, behaves just
as you would expect it to.

No, Randy, not a "Linux distro". Mac OS X is rather a BSD system!

See (!):
http://www.bsd.org/

and/or

http://de.wikipedia.org/wiki/Bild:Unix_history.svg
Sincerely,
G. H.

--

E-mail: info<at>simple-line<Punkt>de

[Randy Howard]

On Tue, 20 Mar 2007 16:55:45 -0500, Gregor H. wrote
(in article <er********************************@4ax.com>):

On Tue, 20 Mar 2007 21:13:52 GMT, Randy Howard
<ra*********@FOOverizonBAR.netwrote:

>>>>>
Firstly, the Standard allows argc to be 0, in which case argv[0] will
be NULL, in which case your usage function has problems.
>
Can you imagine a (real) case where this actually might occur? (I'm
just curios).

I have never owned a Mac, and the last time I used one (that I can
recall) is before I began programming in C, but I am given to
understand that some Mac-based implementations do set argc to 0 and
argv to NULL. I may be mistaken in this regard.

That might have been true in early Mac OS platforms before OS X came
along, I don't have one to try, but OS X, which is basically a properly
built and working Linux distro with a nicer GUI than most, behaves just
as you would expect it to.

No, Randy, not a "Linux distro". Mac OS X is rather a BSD system!

*sigh*
--
Randy Howard (2reply remove FOOBAR)
"The power of accurate observation is called cynicism by those
who have not got it." - George Bernard Shaw

[Richard Tobin]

In article <fv************@news.flash-gordon.me.uk>,
Flash Gordon <sp**@flash-gordon.me.ukwrote:

>Also in Unix when using the non-standard exec* functions

Is it really necessary to call these functions "non-standard" just
because they are specified in a standard other than the ISO C
standard?

-- Richard
--
"Consideration shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.

[Richard Tobin]

In article <00*****************************@news.verizon.net> ,
Randy Howard <ra*********@FOOverizonBAR.netwrote:

>>That might have been true in early Mac OS platforms before OS X came
along, I don't have one to try, but OS X, which is basically a properly
built and working Linux distro with a nicer GUI than most, behaves just
as you would expect it to.

><OT>Nonsense, OS-X is based on BSD</OT>

>I didn't mean genetically. Obviously OS X is not running a Linux
kernel, etc.

I was referring to its behavior. It's what I wanted Linux to be for
over a decade before I gave up on it ever arriving.

Fair enough, if what you mean by a "properly built and working Linux
distro" is FreeBSD :-) I use MacOS X in preference to Linux becauase
it's much more like the BSD unix I'm used to.

-- Richard

--
"Consideration shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.

[Peter Nilsson]

Richard Heathfield <[e-mail]:

Gregor H. said:

Richard Heathfield <[e-mail]:

>
Firstly, the Standard allows argc to be 0, in which case
argv[0] will be NULL, in which case your usage function has
problems.

Can you imagine a (real) case where this actually might occur?
(I'm just curios).

I have never owned a Mac, and the last time I used one (that I
can recall) is before I began programming in C, but I am given
to understand that some Mac-based implementations do set argc
to 0 and argv to NULL.

Yes, which is non-conforming for hosted implementations. By rights,
argv should be non-null and point to a null char * pointer. It
could be argued that they were valid free-standing implementations
though. [Assuming the implementation documented the state of argc
and argv.]

I may be mistaken in this regard.

Nope, you are correct. MacOS < X had no concept of a command line.
Apple's 'Macinsosh Programmer Workshop' came complete with a command
line that did support a shell from which a C program could receive
arguments, but most C implementations did not operate in that
environment. Instead they simply came with a primitive terminal
emulator. Getting command line arguments required a call to a
non-standard function within main...

argc = ccommand(&argv);

The irony is that they were really only set up to work with
main(void), so the argc/argv parameters actually sat _before_
the stack in memory. It just so happened that the memory was
'reserved' by Apple and happened to be zero initialised (though
the Inside Mac bibles gave no indication that this was always
going to be the case.) More correct usage would be...

int main(void)
{
int argc;
char **argv;
argc = ccommand(&argv);

To cut a long story short, it's a 'real' example, but not a
particularly good one. ;-)

--
Peter

[Gregor H.]

On Tue, 20 Mar 2007 22:17:11 GMT, Randy Howard
<ra*********@FOOverizonBAR.netwrote:

>>>>>>
>Firstly, the Standard allows argc to be 0, in which case argv[0] will
>be NULL, in which case your usage function has problems.
>>
Can you imagine a (real) case where this actually might occur? (I'm
just curios).
>
I have never owned a Mac, and the last time I used one (that I can
recall) is before I began programming in C, but I am given to
understand that some Mac-based implementations do set argc to 0 and
argv to NULL. I may be mistaken in this regard.

That might have been true in early Mac OS platforms before OS X came
along, I don't have one to try, but OS X, which is basically a properly
built and working Linux distro with a nicer GUI than most, behaves just
as you would expect it to.

No, Randy, not a "Linux distro". Mac OS X is rather a BSD system!

*sigh*

Keep cool, Randy. But I agree with you concerning Linux. ;-)
G. H.

--

E-mail: info<at>simple-line<Punkt>de

[Richard Heathfield]

Peter Nilsson said:

Richard Heathfield <[e-mail]:

<snip>

>I am given
to understand that some Mac-based implementations do set argc
to 0 and argv to NULL.

Yes, which is non-conforming for hosted implementations. By rights,
argv should be non-null and point to a null char * pointer.

I'm fascinated but sceptical. Can you convince me?

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

[Richard Heathfield]

Richard Tobin said:

In article <fv************@news.flash-gordon.me.uk>,
Flash Gordon <sp**@flash-gordon.me.ukwrote:

>>Also in Unix when using the non-standard exec* functions

Is it really necessary to call these functions "non-standard" just
because they are specified in a standard other than the ISO C
standard?

In comp.lang.c, "standard" tends to mean ISO/IEC 9899 unless otherwise
specified, so it's not unreasonable to call non-ISO functions
"non-standard" even if they are documented in some other standard. In
newsgroups where such standards are topical, presumably exec* /would/
be standard functions. But here, they are not.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

[Mark McIntyre]

On Tue, 20 Mar 2007 21:29:35 +0100, in comp.lang.c , Gregor H.
<nomail@invalidwrote:

>On Tue, 20 Mar 2007 12:38:49 -0700, Keith Thompson <ks***@mib.orgwrote:

>>>
If your claim is true, this claim of K&R is in contradiction to the
standard, right? (Or is this something where ANSI-C and C99 do differ?)

ANSI C and C99 don't differ at all; ANSI has adopted the 1999 ISO C
standard as an ANSI standard.

Yes, we know what you meant.

We? You are many?

Indeed, We are legion.

--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

[Keith Thompson]

"Peter Nilsson" <ai***@acay.com.auwrites:

Richard Heathfield <[e-mail]:

[...]

>I have never owned a Mac, and the last time I used one (that I
can recall) is before I began programming in C, but I am given
to understand that some Mac-based implementations do set argc
to 0 and argv to NULL.

Yes, which is non-conforming for hosted implementations. By rights,
argv should be non-null and point to a null char * pointer. It
could be argued that they were valid free-standing implementations
though. [Assuming the implementation documented the state of argc
and argv.]

[...]

Take a look at C99 5.1.2.2.1, "Program startup". The phrase "If the
value of argc is greater than zero" appears twice. It also says "The
value of argc shall be nonnegative."; if it were intended to require
argc to be at least 1, then that could easily have been stated.

--
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."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[christian.bau]

On Mar 20, 3:49 pm, Gregor H. <nomail@invalidwrote:

On Tue, 20 Mar 2007 11:23:01 +0000, Richard Heathfield

<[e-mail]:

Firstly, the Standard allows argc to be 0, in which case argv[0] will be
NULL, in which case your usage function has problems.

Can you imagine a (real) case where this actually might occur? (I'm just
curios).

K&R are less "pedantic" concerning this point than you are. They write in
K&R2, p. 115:

"By convention, argv[0] is the name by which the program
was invoked, so argc is at least 1."

If your claim is true, this claim of K&R is in contradiction to the
standard, right? (Or is this something where ANSI-C and C99 do differ?)

The C99 draft standard only says that argc >= 0, args [argc] == NULL,
and makes some statements for the case when argc 0. There is no
requirement whatsoever that argc would have to be greater than 0.

[Flash Gordon]

Richard Heathfield wrote, On 20/03/07 22:42:

Peter Nilsson said:

>Richard Heathfield <[e-mail]:

<snip>

>>I am given
to understand that some Mac-based implementations do set argc
to 0 and argv to NULL.

Yes, which is non-conforming for hosted implementations. By rights,
argv should be non-null and point to a null char * pointer.

I'm fascinated but sceptical. Can you convince me?

How about I convince you that you are correct instead? In N1124 section
5.1.2.2.1 it says in part:
| - The value of argc shall be nonnegative.
| - argv[argc] shall be a null pointer.

Then it goes on to specify what happens if argc is greater than zero.
Since nonnegative is normally considered to include 0 (otherwise it
would say positive) and it says greater than zero when that is what it
means, zero is clearly allowed. 5.1.2.2, by the way, is "Hosted
environment".
--
Flash Gordon

[CBFalconer]

NwsGrp1 wrote:

>
A colleague is reading through some C articles and was asked if
there are any errors in the following code. Neither of us can
spot any issues, I have compiled it with VC8 and GCC at their
strictest settings and got nothing of note.

Here is the code:

#include <stdio.h>

void usage(char *ptCommand);

int main(int argc, char * argv[]) {
if (argc < 2)
usage(argv[0]);

return 0;
}

void usage(char *ptCommand) {
char usageInfo[1023];

_snprintf(usageInfo, 1023, "Usage: %s \n", ptCommand);

printf(usageInfo);
}

No such function as "_snprintf".

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>

--
Posted via a free Usenet account from http://www.teranews.com

[Gregor H.]

On Tue, 20 Mar 2007 23:36:14 +0000, Mark McIntyre
<ma**********@spamcop.netwrote:

>>>
Yes, we know what you meant.

We? You are many?

Indeed, We are legion.

Yes, I feared that. We too.
G. H.

--

E-mail: info<at>simple-line<Punkt>de

[CBFalconer]

Richard Tobin wrote:

Flash Gordon <sp**@flash-gordon.me.ukwrote:

>Also in Unix when using the non-standard exec* functions

Is it really necessary to call these functions "non-standard" just
because they are specified in a standard other than the ISO C
standard?

Yes. Otherwise some dewey eyed newbie might get the impression
that they are generally available.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>

--
Posted via a free Usenet account from http://www.teranews.com

[CBFalconer]

Mark McIntyre wrote:

Gregor H. <nomail@invalidwrote:

.... snip ...

>

>We? You are many?

Indeed, We are legion.

I thought the legions left Britain in the 3rd century.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>

--
Posted via a free Usenet account from http://www.teranews.com

[Peter Nilsson]

Flash Gordon <[e-mail]:

Richard Heathfield wrote, On 20/03/07 22:42:

Peter Nilsson said:

Richard Heathfield <[e-mail]:
I am given
to understand that some Mac-based implementations do set argc
to 0 and argv to NULL.

Yes, which is non-conforming for hosted implementations. By
rights, argv should be non-null and point to a null char *
pointer.

I'm fascinated but sceptical. Can you convince me?

Of what?

How about I convince you that you are correct instead?

What's at issue?

In N1124 section 5.1.2.2.1 it says in part:
| - The value of argc shall be nonnegative.
| - argv[argc] shall be a null pointer.

What part of this allows argv to be a null pointer?

Then it goes on to specify what happens if argc is greater than
zero. Since nonnegative is normally considered to include 0
(otherwise it would say positive) and it says greater than zero
when that is what it means, zero is clearly allowed.

Who has said otherwise?

5.1.2.2, by the way, is "Hosted environment".

4p6 begins "The two forms of conforming implementation are hosted
and freestanding."

I mention it for no obvious reason.

--
Peter

[Flash Gordon]

Peter Nilsson wrote, On 21/03/07 04:54:

Flash Gordon <[e-mail]:

>Richard Heathfield wrote, On 20/03/07 22:42:

>>Peter Nilsson said:
Richard Heathfield <[e-mail]:
I am given
to understand that some Mac-based implementations do set argc
to 0 and argv to NULL.
Yes, which is non-conforming for hosted implementations. By
rights, argv should be non-null and point to a null char *
pointer.
I'm fascinated but sceptical. Can you convince me?

Of what?

>How about I convince you that you are correct instead?

What's at issue?

>In N1124 section 5.1.2.2.1 it says in part:
| - The value of argc shall be nonnegative.
| - argv[argc] shall be a null pointer.

What part of this allows argv to be a null pointer?

<snip>

I, and probably others, read "argv to NULL" as "argv[0] to NULL". There
is a strong tendency to ready what you expect to see rather than what is
there. I agree that argv cannot be set to null by a conforming
implementation.
--
Flash Gordon

[Richard Heathfield]

Peter Nilsson said:

Flash Gordon <[e-mail]:

>Richard Heathfield wrote, On 20/03/07 22:42:

Peter Nilsson said:
Richard Heathfield <[e-mail]:
I am given
to understand that some Mac-based implementations do set argc
to 0 and argv to NULL.

<snip>

>In N1124 section 5.1.2.2.1 it says in part:
| - The value of argc shall be nonnegative.
| - argv[argc] shall be a null pointer.

What part of this allows argv to be a null pointer?

OHHHHHHHHHHHHHHHH, I see! I didn't even notice that. My typo, so mea
culpa. I did of course mean argv[0].

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

[Keith Thompson]

Keith Thompson <ks***@mib.orgwrites:

"Peter Nilsson" <ai***@acay.com.auwrites:

>Richard Heathfield <[e-mail]:

[...]

>>I have never owned a Mac, and the last time I used one (that I
can recall) is before I began programming in C, but I am given
to understand that some Mac-based implementations do set argc
to 0 and argv to NULL.

Yes, which is non-conforming for hosted implementations. By rights,
argv should be non-null and point to a null char * pointer. It
could be argued that they were valid free-standing implementations
though. [Assuming the implementation documented the state of argc
and argv.]

[...]

Take a look at C99 5.1.2.2.1, "Program startup". The phrase "If the
value of argc is greater than zero" appears twice. It also says "The
value of argc shall be nonnegative."; if it were intended to require
argc to be at least 1, then that could easily have been stated.

Whoops, I mis-read it, as Peter Nilsson points out in another followup
in this thread. argc can be 0 and argv[0] can be a null pointer (and
in fact it must be if argc==0), but the very existence of argv[0]
implies that argv itself must be non-null.

--
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."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Army1987]

>void usage(char *ptCommand) {
char usageInfo[1023];

_snprintf(usageInfo, 1023, "Usage: %s \n", ptCommand);

printf(usageInfo);
}

Thank you.

Use
printf("%s", usageInfo)
in case ptCommand contains format specifiers.

That's why I don't usually use printf if a simpler function works.

void usage(char *ptCommand) {
printf("Usage: ");
puts(ptCommand);
}

Or even fputs(stdout, "Usage: ");

[Keith Thompson]

"Army1987" <pl********@for.itwrites:

>>void usage(char *ptCommand) {
char usageInfo[1023];

_snprintf(usageInfo, 1023, "Usage: %s \n", ptCommand);

printf(usageInfo);
}

Thank you.

Use
printf("%s", usageInfo)
in case ptCommand contains format specifiers.

That's why I don't usually use printf if a simpler function works.

void usage(char *ptCommand) {
printf("Usage: ");
puts(ptCommand);
}

Or even fputs(stdout, "Usage: ");

Or even fputs("Usage: ", stdout);

(Incidentally, please don't delete attribution lines.)

--
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."
-- Antony Jay and Jonathan Lynn, "Yes Minister"