Re: What's wrong ?



CBFalconer <cbfalconer@xxxxxxxxx> writes:
"Daniel.C" wrote:

I just copied this code from my book with no modification :

#include <stdio.h>
/* count characters in input; 1st version */
main()

int main(void)

Yes, that's an improvement.

{
long nc;

nc = 0;
while (getchar() != EOF)
++nc;
printf("%ld\n", nc);

return 0;

Yes, that's also an improvement.

}

There is no output, and no completion either. I tried adding a
"printf" at the end of the code, but it doesn't display.

Your book is obsolete and wrong. C99 requires the int in the
declaration of main, and the void for parameters is just good
practice. C99 will supply a default return value, but earlier
standards don't. Thus your code is wrong for any version.

Neither version of the standard defines the term "wrong", so it's not
clear what you're talking about.

The declaration "main()" is legal for C90. (There's a subtle argument
that the void keyword might be necessary, but since ANSI was careful
not to break existing code, it was clearly the intent that
"main() { ... }" should be acceptable.)

Support for C90 is much more widespread than support for C99, and even
compilers that do support C99 will almost certainly do no more than
issue a warning for the implicit int return type. (Which is not to
say that such a warning should be ignored, of course.)

As for the missing return statement, in C90 that merely causes an
undefined status to be returned to the calling environment. If the
environment doesn't use the status (say, if you type "./prog" to a
Unix shell), then this likely won't make any difference; at worst, it
might result in some harmless message after the program terminates.

Having said that, yes, both changes you suggest are certainly
improvements, but they don't necessarily tranform the program from
being "wrong" to being "right".

If it doesn't work with the above simple changes, your compiler
system is fouled.

If the above simple changes make any relevant difference to the
behavior of the program, I'll be astonished. We now know what the
problem was, and it would have shown up in exactly the same way with
your suggested changes in place.

I probably would have mentioned these things myself if they hadn't
already been covered by others. Actually, though, what bothered me
more was the way the source code was formatted. Here's a modified
version of the program with your changes and better layout (I also
added a pair of braces):

#include <stdio.h>
/* count characters in input; 1st version */
int main(void)
{
long nc;

nc = 0;
while (getchar() != EOF) {
++nc;
}
printf("%ld\n", nc);
return 0;
}

The point here (I'm addressing the OP now) is that consistent
indentation makes the structure of the program much easier to see. It
doesn't matter much for something this small, but it's vital for
larger and more complex programs, and it's a good idea to get into the
habit as early as possible.

--
Keith Thompson (The_Other_Keith) <kst-u@xxxxxxx>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
.



Relevant Pages

  • Re: Help with strings
    ... int zz=0; ... This defaults to int in C90. ... However, C99 forbids this. ... that does not compare equal to any member of the execution character ...
    (comp.lang.c)
  • Re: Happy New Year!
    ... which was not a valid C90 code anyway, ... int main ... Someday (probably in the C99 committee) one suggested, ... provided (while in C90 const x; was equivalent to const int x; for ...
    (comp.lang.cpp)
  • Re: doubt regarding sizeof operator
    ... converting to int and using "%d" is not unreasonable. ... In C90, size_t cannot be bigger than unsigned long, so "%lu" is safe. ... In C99, "%zu" is supported. ...
    (comp.lang.c)
  • Re: I have a question
    ... int j = i; ... For C90, ... Clearly it is C99 example in this case. ... how for and switch statements work. ...
    (comp.lang.c)
  • Re: An example of unions not being type safe?
    ... The behaviour is implementation-defined in C90, ... C99. ... also say that an int is not typesafe because ... What makes it possible to break the type system is the existence of ...
    (comp.lang.c)