code question

[Richard]

Thanks Richard I know I can always count on you. I wondered about
argc and its uses.

In addition to argc, argv is also NULL terminated (IIRC!), so
you can loop through it without needed argc to find out when
to stop.

while(*argv)
{
process(*argv);
++argv;
}

I'm not sure that is safe. Check whether argv[0] can be a NULL.

Oops! The first line should be
while(argv)
or
while(argv != NULL)

..without the dereference.

No. With the dereference. Not a typo so a fundamental misunderstanding
of the basic use of pointers there. I can only assume beer has been
consumed :-;

 

[Richard]

Thanks Richard I know I can always count on you. I wondered about
argc and its uses.
In addition to argc, argv is also NULL terminated (IIRC!), so
you can loop through it without needed argc to find out when
to stop.

while(*argv)
{
process(*argv);
++argv;
}

I'm not sure that is safe. Check whether argv[0] can be a NULL.

Did you bother to read Richard's reply?

Interestingly enough I must admit to never having seen or heard of that
before.

And I guess the resulting C code would be something like:

for(;*argv;process(*argv++));

or

for(char *p=*argv++; p; process(p));

Since you have to read the contents of the address pointed to by argv
anyway the compiler is clever enough in most cases to mean that using a
decrement and branch like argc-- is not any faster except for the last
null case.

 

[Ben Bacarisse]

Are you sure it is not "x ~= 34;"? Have you checked the published
errata sheet? I greatly doubt that K&R have suppressed the blanks
as you have.

I think it is very unlikely that K&R made this mistake either with or
without the spaces. I don't have K&R2 but since there is no published
correction we can safely assume that Bill Cunningham is mistaken.

In my K&R (1 not 2) the example is:

~ finds use in expressions such as

x & ~077

 

[Nick Keighley]

K&R is the best introduction to a programming language I have seen. Bar
none.

I've known complete beginners to struggle. Its a great intoduction to
C but a bit information densed to learn programming from.

 

[Richard]

I've known complete beginners to struggle. Its a great intoduction to
C but a bit information densed to learn programming from.

I said introduction to a programming language. Not as an introduction to
programming. Although I also think its pretty good at that too.

As we all learnt recently the only introduction to programming is Knuth
and there are various posters here on record as saying its great to "dip
into" for the beginner .... LOL.

Here#s a section on bitwise operators. This should help Bill!

http://www-cs-faculty.stanford.edu/~uno/fasc1a.ps.gz

--

 

[Barry Schwarz]

In addition to argc, argv is also NULL terminated (IIRC!), so
you can loop through it without needed argc to find out when
to stop.

while(*argv)
{
process(*argv);
++argv;
}

I'm not sure that is safe. Check whether argv[0] can be a NULL.

Isn't that what the first line does?

 

[Barry Schwarz]

Are you sure it is not "x ~= 34;"? Have you checked the published
errata sheet? I greatly doubt that K&R have suppressed the blanks
as you have.

Since there no character sequence "34" on page 49 (or 48 or 50) of K&R
2 nor is there any character sequence "x~" (with or without
intervening spaces), Bill's question makes even less sense than usual.
I expect he is just guessing at the contents of the book the same way
he guesses at the meaning of C constructs.

 

[Barry Schwarz]

On Fri, 19 Sep 2008 16:52:17 -0400, "Bill Cunningham"

if ((fp = fopen(argv[4], "a")) == NULL) {

At the same time, it should be a file name.

That doesn't strike you as slightly odd?

A filename input is an argument. I thought you treated it as such. There are
many things that kandr2 doesn't teach you. Things like this for example.
That why clc is needed.

Since you deliberately omitted the first half of the question, your
response is completely irrelevant.

However, it does offer additional proof that you are not the slightest
bit interested in learning from the advice given here.

 

[Default User]

And in a way, that makes him an excellent programmer of the wetware
of the people who just can't help not responding to him, time after
time after time.

I don't know and I don't much care. Bill is either a troll, or has been
"studying" C for at LEAST five years and made no more progress than
this. If he's not a troll, then I don't see any reason to think that
another five years or fifty years of CLC pouring out their advice will
make the slightest difference.

Replying to Bill is a waste of time one way or the other.




Brian

 

[Martien Verbruggen]

Are you sure it is not "x ~= 34;"? Have you checked the published
errata sheet? I greatly doubt that K&R have suppressed the blanks
as you have.

I don't think Bill is saying that that question or that phrase appear on
that page. I think he's saying that that was his question, and someone
else told him that the answer to that could be found on page 49 of K&R2.

Martien

 

[CBFalconer]

Thanks Richard I know I can always count on you. I wondered
about argc and its uses.

In addition to argc, argv is also NULL terminated (IIRC!), so
you can loop through it without needed argc to find out when
to stop.

while (*argv) {
process(*argv);
++argv;
}

I'm not sure that is safe. Check whether argv[0] can be a NULL.

Isn't that what the first line does?

My point, which I haven't bothered to check, is that on some
systems argv[0] doesn't point to an identifier of the program. If
that is the case, is argv[0] value NULL, or does it point to an
empty string? If it is a NULL, the scanning sequence won't work.

 

[Richard]

Andrew Poelstra wrote:

Thanks Richard I know I can always count on you. I wondered
about argc and its uses.

In addition to argc, argv is also NULL terminated (IIRC!), so
you can loop through it without needed argc to find out when
to stop.

while (*argv) {
process(*argv);
++argv;
}

I'm not sure that is safe. Check whether argv[0] can be a NULL.

Isn't that what the first line does?

My point, which I haven't bothered to check, is that on some
systems argv[0] doesn't point to an identifier of the program. If

What systems?

However IF the standard says that the first non existent argument slot
is NULL e.g

"myprog" then argv[1] is null then there really is not a problem if the
correct indices are used.

for(;*++argv;process(*argv));

 

[Ben Bacarisse]

Andrew Poelstra wrote:

Thanks Richard I know I can always count on you. I wondered
about argc and its uses.

In addition to argc, argv is also NULL terminated (IIRC!), so
you can loop through it without needed argc to find out when
to stop.

while (*argv) {
process(*argv);
++argv;
}

I'm not sure that is safe. Check whether argv[0] can be a NULL.

Isn't that what the first line does?

My point, which I haven't bothered to check, is that on some
systems argv[0] doesn't point to an identifier of the program. If
that is the case, is argv[0] value NULL, or does it point to an
empty string? If it is a NULL, the scanning sequence won't work.

It might have been better to check. The code is fine. argv[0] can
only be NULL if argc == 0 in C90 and C99.

It is odd as it stands (because it processes a non-NULL argv[0] like
any other argument) but it is not wrong. It may, of course, be only a
fragment in which case it may not even be odd.

 

[Barry Schwarz]

Andrew Poelstra wrote:

Thanks Richard I know I can always count on you. I wondered
about argc and its uses.

In addition to argc, argv is also NULL terminated (IIRC!), so
you can loop through it without needed argc to find out when
to stop.

while (*argv) {
process(*argv);
++argv;
}

I'm not sure that is safe. Check whether argv[0] can be a NULL.

Isn't that what the first line does?

My point, which I haven't bothered to check, is that on some
systems argv[0] doesn't point to an identifier of the program. If
that is the case, is argv[0] value NULL, or does it point to an
empty string? If it is a NULL, the scanning sequence won't work.

Since 5.1.2.2.1 guarantees argc >= 0 and argv[argc] == NULL, the
situation you are concerned about cannot occur.

 

[Richard]

Andrew Poelstra wrote:

Thanks Richard I know I can always count on you. I wondered
about argc and its uses.

In addition to argc, argv is also NULL terminated (IIRC!), so
you can loop through it without needed argc to find out when
to stop.

while (*argv) {
process(*argv);
++argv;
}

I'm not sure that is safe. Check whether argv[0] can be a NULL.

Isn't that what the first line does?

My point, which I haven't bothered to check, is that on some
systems argv[0] doesn't point to an identifier of the program. If
that is the case, is argv[0] value NULL, or does it point to an
empty string? If it is a NULL, the scanning sequence won't work.

Since 5.1.2.2.1 guarantees argc >= 0 and argv[argc] == NULL, the
situation you are concerned about cannot occur.

He wasn't concerned. He specifically said that he wasn't bothered enough
to check. if everything Chuck was not sure of solicited such posts from
him we would be here all night. Thankfully he cherry picks the threads
he wishes to confuse and FUD(*).

For the regs who will pretend not to know what "FUD" is, I provide this
link as a service to your coming of age,

http://en.wikipedia.org/wiki/Fear,_uncertainty_and_doubt

 

[Richard]

Default User said: [...]

Replying to Bill is a waste of time one way or the other.

I agree that Bill Cunningham doesn't appear to gain any significant benefit
from the responses he gets. Whether this is through malice or incompetence
is really beside the point, and Hanlon's Razor applies.

But his questions do sometimes provoke discussions that are likely to be of
moderate interest to /other/ learners. If you think of a reply to one of
Bill Cunningham's articles not as a reply to /him/, but as a reply to the
points he has made, for general consumption, then it may perhaps seem
slightly less of a Sisyphean task.

Good point, but following it would mean answering his questions and not
replying further when he ignores the answer or mentions his copy of
"kandr2" from an alternate universe.

Actually its not a good point at all. Primarily because Bill is yet to
ask a half decent question. He rarely if ever seems to know what he
wants leading to a rush of good Samaritans answering the question they
want it to be rather than the one he, supposedly, meant it to be.

 

[Default User]

Default User said:


I agree that Bill Cunningham doesn't appear to gain any significant
benefit from the responses he gets. Whether this is through malice or
incompetence is really beside the point, and Hanlon's Razor applies.

But his questions do sometimes provoke discussions that are likely to
be of moderate interest to other learners. If you think of a reply to
one of Bill Cunningham's articles not as a reply to him, but as a
reply to the points he has made, for general consumption, then it may
perhaps seem slightly less of a Sisyphean task.

I'll freely admit that I still read through the threads, even though I
have Bill killfiled. Indeed, there's sometimes a useful nugget. Each
will have to make a decision on how to approach it.




Brian

 

[Keith Thompson]

argv[0] is guaranteed *either* to represent the program name or to be NULL
(and argc to be 0), and the scanning sequence works fine whichever of
these is the case.

[...]

argv[0] is also allowed to point to an empty string if the program
name is not available. The standard's exact wording (C99 5.1.2.2.1p2)
is:

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.

But the requirement that the string pointed to by argv[0][0]
"represents the program name" is largely unenforced and unenforceable.
Under POSIX, for example, the string is whatever the invoking program
wants it to be. Though I suppose you could define "program name" in
such a way as to make this consistent. In fact, since "program name"
is in italics in the quoted paragraph, that supposedly *is* the
definition of the phrase -- though I'm not convinced it's really a
definition at all. It would make as much sense, and be more
consistent, for the standard to say that the string *is* the program
name.

 

[CBFalconer]

.... snip ...

My point, which I haven't bothered to check, is that on some
systems argv[0] doesn't point to an identifier of the program. If
that is the case, is argv[0] value NULL, or does it point to an
empty string? If it is a NULL, the scanning sequence won't work.

Since 5.1.2.2.1 guarantees argc >= 0 and argv[argc] == NULL, the
situation you are concerned about cannot occur.

I wasn't talking about argv[argc]. I mentioned argv[0].
Apparently there is no worry.

 

[CBFalconer]

CBFalconer said:
.... snip ...

My point, which I haven't bothered to check, is that on some
systems argv[0] doesn't point to an identifier of the program. If
that is the case, is argv[0] value NULL, or does it point to an
empty string? If it is a NULL, the scanning sequence won't work.

argv[0] is guaranteed *either* to represent the program name or to
be NULL (and argc to be 0), and the scanning sequence works fine
whichever of these is the case.

In future, please bother to check.

Don't be so silly. I'm not worried about using it. I simply
raised something for others, who might be worried, to check.