Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > What's wrong ?

Reply
Thread Tools

What's wrong ?

 
 
Keith Thompson
Guest
Posts: n/a
 
      03-06-2008
CBFalconer <(E-Mail Removed)> 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) <(E-Mail Removed)>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
Reply With Quote
 
 
 
 
Richard
Guest
Posts: n/a
 
      03-06-2008
santosh <(E-Mail Removed)> writes:

> CBFalconer wrote:
>
>> "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)
>>
>>> {
>>> long nc;
>>>
>>> nc = 0;
>>> while (getchar() != EOF)
>>> ++nc;
>>> printf("%ld\n", nc);

>>
>> return 0;
>>
>>> }
>>>
>>> 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.

>
> The example probably came from K&R2. So you are saying it's obsolete and
> wrong. On what basis?


This should be good....
 
Reply With Quote
 
 
 
 
CBFalconer
Guest
Posts: n/a
 
      03-06-2008
santosh wrote:
> CBFalconer wrote:
>> "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) <<< **** CHECK THIS *****
>>
>>> {
>>> long nc;
>>>
>>> nc = 0;
>>> while (getchar() != EOF)
>>> ++nc;
>>> printf("%ld\n", nc);

>>
>> return 0; <<< **** AND THIS *****
>>
>>> }
>>>
>>> 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.

>
> The example probably came from K&R2. So you are saying it's obsolete and
> wrong. On what basis?
>
> > 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.

>
> They were omitted for brevity, as you well know.


As I explained above, one of the error fouls C89 thru C95, the
other fouls on C99. So his compiler is accepting erroneous code -
no need to encourage it. Of course I didn't think of the simple
solution of the OP not knowing how to signal EOF. But that is
another subject. The code is still WRONG.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.



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

 
Reply With Quote
 
CBFalconer
Guest
Posts: n/a
 
      03-06-2008
Keith Thompson wrote:
>

.... snip ...
>
> 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.)


I wonder. Since int is no longer a default type, the untyped
procedure definition is, I think, a syntax error, and requires a
complaint. The standard doesn't differentiate between errors and
warnings or anything else.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.



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

 
Reply With Quote
 
Falcon Kirtaran
Guest
Posts: n/a
 
      03-07-2008
Daniel.C wrote:
> Hello.
> I just copied this code from my book with no modification :
>
> #include <stdio.h>
> /* count characters in input; 1st version */
> main()
> {
> long nc;
>
> nc = 0;
> while (getchar() != EOF)
> ++nc;
> printf("%ld\n", nc);
> }
>
> There is no output, and no completion either. I tried adding a "printf" at
> the end of the code, but it doesn't display.
>
> i'm using MinGW developer studio with windows XP home.
>
> Thanks in advance.
> Daniel
>
>


Firstly, you ought to use Linux instead, but that is moot

To answer your question, what is the command line you use to run your
program?

If it is something like "a.out < file" EOF will actually be sent to
stdin (where your program is reading data from) when the file "file"
ends. However, if you ran it like "a.out", stdin is connected to your
tty (console) and the program is waiting for EOF (and looking like it
hung). Most standard UNIX consoles will allow you to type control-d for
EOF; try typing your input and then this. Enter simply inputs the
newline sequence, which is not EOF.

--
--Falcon Kirtaran
 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      03-07-2008
CBFalconer <(E-Mail Removed)> writes:
> Keith Thompson wrote:
> ... snip ...
>>
>> 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.)

>
> I wonder. Since int is no longer a default type, the untyped
> procedure definition is, I think, a syntax error, and requires a
> complaint. The standard doesn't differentiate between errors and
> warnings or anything else.


Right, and a pure C99 implementation certainly *could* treat "main()"
as a syntax error. But I doubt that any of them do so. I suspect
that most or all of them use a grammar that recognizes implicit int so
they can print a meaningful error message (or allow it either as an
extension or in a C90-conforming mode).

--
Keith Thompson (The_Other_Keith) <(E-Mail Removed)>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
Reply With Quote
 
Daniel.C
Guest
Posts: n/a
 
      03-07-2008
Many thanks.
Daniel
"Falcon Kirtaran" <(E-Mail Removed)> a écrit dans le message de
news: fqqb5k$7a3$(E-Mail Removed)...
> Daniel.C wrote:
>> Hello.
>> I just copied this code from my book with no modification :
>>
>> #include <stdio.h>
>> /* count characters in input; 1st version */
>> main()
>> {
>> long nc;
>>
>> nc = 0;
>> while (getchar() != EOF)
>> ++nc;
>> printf("%ld\n", nc);
>> }
>>
>> There is no output, and no completion either. I tried adding a "printf"
>> at the end of the code, but it doesn't display.
>>
>> i'm using MinGW developer studio with windows XP home.
>>
>> Thanks in advance.
>> Daniel

>
> Firstly, you ought to use Linux instead, but that is moot
>
> To answer your question, what is the command line you use to run your
> program?
>
> If it is something like "a.out < file" EOF will actually be sent to stdin
> (where your program is reading data from) when the file "file" ends.
> However, if you ran it like "a.out", stdin is connected to your tty
> (console) and the program is waiting for EOF (and looking like it hung).
> Most standard UNIX consoles will allow you to type control-d for EOF; try
> typing your input and then this. Enter simply inputs the newline
> sequence, which is not EOF.
>
> --
> --Falcon Kirtaran



 
Reply With Quote
 
santosh
Guest
Posts: n/a
 
      03-07-2008
CBFalconer wrote:

> santosh wrote:
>> CBFalconer wrote:
>>> "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) <<< **** CHECK THIS *****
>>>
>>>> {
>>>> long nc;
>>>>
>>>> nc = 0;
>>>> while (getchar() != EOF)
>>>> ++nc;
>>>> printf("%ld\n", nc);
>>>
>>> return 0; <<< **** AND THIS *****
>>>
>>>> }
>>>>
>>>> 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.

>>
>> The example probably came from K&R2. So you are saying it's obsolete
>> and wrong. On what basis?
>>
>> > 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.

>>
>> They were omitted for brevity, as you well know.

>
> As I explained above, one of the error fouls C89 thru C95, the
> other fouls on C99. So his compiler is accepting erroneous code -
> no need to encourage it. Of course I didn't think of the simple
> solution of the OP not knowing how to signal EOF. But that is
> another subject. The code is still WRONG.


The program isn't in error for C90. It merely returns an unspecified
status value. I don't think that invokes undefined behaviour.

 
Reply With Quote
 
CBFalconer
Guest
Posts: n/a
 
      03-07-2008
santosh wrote:
> CBFalconer wrote:
>

.... snip ...
>
>> As I explained above, one of the error fouls C89 thru C95, the
>> other fouls on C99. So his compiler is accepting erroneous code
>> - no need to encourage it. Of course I didn't think of the
>> simple solution of the OP not knowing how to signal EOF. But
>> that is another subject. The code is still WRONG.

>
> The program isn't in error for C90. It merely returns an unspecified
> status value. I don't think that invokes undefined behaviour.


Why shouldn't the OS have a provision: I won't display the output
unless the program completes successfully?

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.



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

 
Reply With Quote
 
Richard Heathfield
Guest
Posts: n/a
 
      03-07-2008
santosh said:

> CBFalconer wrote:
>


<snip>

>>>> Your book is obsolete and wrong.
>>>
>>> The example probably came from K&R2. So you are saying it's obsolete
>>> and wrong. On what basis?


The example is indeed from K&R2 (top of page 18, in fact). K&R2 is neither
obsolete nor wrong.

<snip>

>> As I explained above, one of the error fouls C89 thru C95,


No, it doesn't. The behaviour of the program under C89 through C95 is
well-defined. The *termination status* is undefined, but that isn't an
error.

>> the
>> other fouls on C99.


....for which everyone and his cat has a conforming compiler, of course. I
Don't Think So.

>> So his compiler is accepting erroneous code -


No, his compiler is accepting correct code. I consider Chuck's amendments
to improve the style of the code, but the code as written works just fine.

>> no need to encourage it. Of course I didn't think of the simple
>> solution of the OP not knowing how to signal EOF. But that is
>> another subject. The code is still WRONG.

>
> The program isn't in error for C90. It merely returns an unspecified
> status value. I don't think that invokes undefined behaviour.


Well, it's an undefined termination status, but that's all. The program
does not rely on any unspecified, undefined, or implementation-defined
behaviour (unless you count the possibility of overflowing a long int,
which would take quite a while to achieve), so it can be argued that it is
strictly conforming.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Have I bought wrong product? enquirer Wireless Networking 2 06-10-2005 10:59 PM
Zero Config keeps connecting to the wrong AP =?Utf-8?B?ZGdyaWZmaXRo?= Wireless Networking 2 03-04-2005 05:52 PM
Is XML Doc wrong or is Schema wrong? (or both) Matthew XML 7 01-07-2005 10:05 PM
wrong connection status Peter Welk Wireless Networking 0 12-22-2004 03:26 PM
XP SP2 Wrong IP on connection D Wells Wireless Networking 3 12-09-2004 03:35 AM



Advertisments