Is this C program doing what it is supposed to do ?

[John]

The program is supposed to read lines from the standard input, then each line is printed on the standard output preceded by its line number. The program should have no built-on limit on how long a line it can handle.

So I wrote the following program in C, but I'm not sure that it is doing what it is supposed to do. I verified the source code against the solution in the back of the book and I'm pasting here what the solution in the back of the book is.

#include<stdio.h>
#include<stdlib.h>

int main(){

int ch;
int at_beginning = 1;
int line = 0;

while( (ch==getchar())!= EOF){

if(at_beginning == 1){

at_beginning = 0;
line+=1;
printf("%d ", line);

}

putchar(ch);

if(ch == '\n')
at_beginning = 1;
}
return EXIT_SUCCESS;
}

 

[Eric Sosman]

The program is supposed to read lines from the standard input, then each line is printed on the standard output preceded by its line number. The program should have no built-on limit on how long a line it can handle.

So I wrote the following program in C, but I'm not sure that it is doing what it is supposed to do. I verified the source code against the solution in the back of the book and I'm pasting here what the solution in the back of the book is.

#include<stdio.h>
#include<stdlib.h>

int main(){

int ch;
int at_beginning = 1;
int line = 0;

while( (ch==getchar())!= EOF){

You want `=' instead of `==' here. (This may be the first time
I've seen the "equals/assign" mistake in this direction; usually, it's
using `=' where `==' is meant, not the other way around.)

 

[Ben Bacarisse]

The program is supposed to read lines from the standard input, then each line is printed on the standard output preceded by its line number. The program should have no built-on limit on how long a line it can handle.

So I wrote the following program in C, but I'm not sure that it is doing what it is supposed to do. I verified the source code against the solution in the back of the book and I'm pasting here what the solution in the back of the book is.

#include<stdio.h>
#include<stdlib.h>

int main(){

int main(void) is better. It hardly matters for main, but for other
functions using the form with void will enable proper function prototype
checking so it's worth getting into the habit.

int ch;
int at_beginning = 1;
int line = 0;

while( (ch==getchar())!= EOF){

== confused with = already commented on.

if(at_beginning == 1){

It's usually better to write:

if (at_beginning) { ...

at_beginning = 0;
line+=1;
printf("%d ", line);

}

putchar(ch);

if(ch == '\n')
at_beginning = 1;

and here I'd write

at_beginning = ch == '\n';

This way the reader can see at once when at_beginning is 0 and when it
is 1. The earlier assignment becomes redundant.

 

[Chris H]

In message <0.8a2a169873977757779c.20110130214737GMT.87k4hm5aiu.fsf@bsb.

It's usually better to write:

if (at_beginning) { ...

No it isn't

and here I'd write

at_beginning = ch == '\n';

Appalling! And dangerous.

 

[Eric Sosman]

In message<0.8a2a169873977757779c.20110130214737GMT.87k4hm5aiu.fsf@bsb.


No it isn't

De gustibus non disputandum est.

Appalling! And dangerous.

Balderdash! And ignorant.

 

[Chris H]

De gustibus non disputandum est.


Balderdash! And ignorant.

The OP has already made one mistake with = and ==
The line is dangerous.

 

[Ben Bacarisse]

The OP has already made one mistake with = and ==
The line is dangerous.

The original code (to which I was offering this alternative) has the
same set of operators so it would seem to offer the same opportunities
for =/== confusion. You also snipped my supporting argument. What is
your argument in support of the original (or against my alternative)?

 

[Chris H]

In message <0.c67692d26d53aa1f6676.20110131132623GMT.87ei7t5hmo.fsf@bsb.

The original code (to which I was offering this alternative) has the
same set of operators so it would seem to offer the same opportunities
for =/== confusion. You also snipped my supporting argument. What is
your argument in support of the original (or against my alternative)?

Er what argument for it? There wasn't one.

 

[Joachim Schmitz]

In message


Er what argument for it? There wasn't one.

This one :

This way the reader can see at once when at_beginning is 0 and when it
is 1. The earlier assignment becomes redundant.

Bye, Jojo

 

[Chris H]

This one :

Bye, Jojo

So there is no argument to support it then and it is dangerous.

 

[Rui Maciel]

Er what argument for it? There wasn't one.

You are free to read Ben's post, the one which you replied to.

In spite of this, if you wish to present a better alternative you are
compelled to demonstrate why your suggestion is better.


Rui Maciel

 

[Keith Thompson]

In message <0.8a2a169873977757779c.20110130214737GMT.87k4hm5aiu.fsf@bsb.


No it isn't

Why? I've read several other followups in this thread, and I
haven't seen you provide any supporting arguments for this.

at_beginning is treated as a boolean. It would make sense to declare it
as bool or _Bool if the compiler supports it. Why is an explicit
comparison against 1 better than a simple test of the variable?

"if (at_beginning)" expresses the intent more clearly than
"if (at_beginning == 1)". And since "==" yields a logically boolean
result, why stop at one "=="; why not write
"if ((at_beginning == 1) == 1)"?

In this particular case, at_beginning can only have the value 0 or
1, but of course any non-zero value is treated as true. What if,
in a later version of the program, at_beginning is assigned the
result of one of the is*() functions?

Appalling! And dangerous.

I presume there's some reason behind your reaction, but I honestly
can't think of what it might be. Yes, the OP made an "=" vs. "=="
error. Surely the solution is to avoid making such errors --
which, I think, are no more likely with the suggested change than
without it.

 

[Ian Collins]

I presume there's some reason behind your reaction, but I honestly
can't think of what it might be. Yes, the OP made an "=" vs. "=="
error. Surely the solution is to avoid making such errors --
which, I think, are no more likely with the suggested change than
without it.

at_beginning = (ch == '\n');

is probably clearer to many.

 

[Rui Maciel]

He is not compelled to do any such thing. This being usenet, he can
post pretty much anything that he wants to. You may well feel that he
has an obligation to explain himself, and I would agree with you, but
again he is quite at liberty to ignore our feelings in the mat

This is a public forum dedicated to the discussion of a series of
technical issues involving a specific programming language.

With this in mind, if someone wishes to participate in a discussion on
any technical issue involving this particular programming language and he
wishes to do so by throwing criticism at other people's work then, at the
very least, that person must be able to objectively base his comments in
any tangible and reasonable technical aspect. Otherwise their criticism
only contributes to the noise level in this newsgroup.

In this case, we saw a user throwing baseless claims that he is unable to
substantiate. This is pure noise and lacks any value. So, by pointing
out that if someone wishes to badmouth other people's work then that
person is compelled to base their claims, in essence what's being told is
that this sort of critics should either put up or shut up. Otherwise no
one stands to gain anything from this sort of behavior.


Rui Maciel

 

[Chris H]

This is a public forum dedicated to the discussion of a series of
technical issues involving a specific programming language.

With this in mind, if someone wishes to participate in a discussion on
any technical issue involving this particular programming language and he
wishes to do so by throwing criticism at other people's work then, at the
very least, that person must be able to objectively base his comments in
any tangible and reasonable technical aspect. Otherwise their criticism
only contributes to the noise level in this newsgroup.

In this case, we saw a user throwing baseless claims that he is unable to
substantiate.

Can you prove that statement?

This is pure noise and lacks any value. So, by pointing
out that if someone wishes to badmouth other people's work then that
person is compelled to base their claims, in essence what's being told is
that this sort of critics should either put up or shut up. Otherwise no
one stands to gain anything from this sort of behavior.


Rui Maciel

Now I know why I so rarely post to this forum

 

[Keith Thompson]

In message <[email protected]>, Rui Maciel


Now I know why I so rarely post to this forum

Chris, I hope this discussion won't prevent you from sharing with
us the reasoning behind your statements. I really would like to
know what you had in mind.

 

[Keith Thompson]

at_beginning = (ch == '\n');

is probably clearer to many.

Agreed. I'd probably write it that way myself.

I think some people have a little trouble with the idea of using
Boolean values and expressions in contexts other than explicit
conditions. (By "Boolean", I don't necessarily mean something of
type bool or _Bool, just something that's logically true-or-false.
C has traditionally used int for this purpose.) If you don't think
of a Boolean value as a value, it makes sense to write something like

if (foo == bar) {
flag = 1;
}
else {
flag = 0;
}

rather than just

flag = (foo == bar);

whereas I rather strongly prefer the latter.

I'm not saying that that's Chris H's issue. I still don't know
what he's complaining about, but I'd like to.

 

[Keith Thompson]

Agreed. I'd probably write it that way myself.

I think some people have a little trouble with the idea of using
Boolean values and expressions in contexts other than explicit
conditions. (By "Boolean", I don't necessarily mean something of
type bool or _Bool, just something that's logically true-or-false.
C has traditionally used int for this purpose.) If you don't think
of a Boolean value as a value, it makes sense to write something like

if (foo == bar) {
flag = 1;
}
else {
flag = 0;
}

rather than just

flag = (foo == bar);

whereas I rather strongly prefer the latter.

I'm not saying that that's Chris H's issue. I still don't know
what he's complaining about, but I'd like to.

Hmm. My comments above were based mostly on the responses; I hadn't
looked closely at the original code, and I made some incorrect
assumptions about it. Now that I look at it, the issue isn't as
straightforward as I had assumed.

 

[Marcin Grzegorczyk]

You never cease to amaze. You really think an embedded systems C
programmer has a problem with such a basic C concept?

Obviously your opinion about the average programming skills of embedded
systems C programmers is higher than mine ;->

(Disclaimer: No offence to anyone in particular intended. And I said
*average* skills, not Chris H's skills.)

 

[Walter Banks]

You never cease to amaze. You really think an embedded systems C
programmer has a problem with such a basic C concept?

Nothing would surprise in what a C programmer might do. I wish
I had a nickel for every support call I have taken in the last quarter
century when = and == were confused or a define had a ';' at the
end creating macro expansion with unexpected results.


Regards,


w..