scanf(), ungetc() behaviour.

[Ben Bacarisse]

Are you serious about this? Before you answer that first question, I would
just want you to know, those course books are from OUHK (Open University
of Hong Kong, that's where I currently study about this) taken from the
course code MT258.

I would not push this too far if I were you. I have had a look at some
of the TMA solutions and there are worse errors in there the void main()
and fflush(stdin)! One solution has some very odd logic (I can't say
"wrong" because the spec. is not given in the solution paper so it is
possible the strange behaviour is allowed). In one place in the
supporting material by the same author gets and scanf("%[\n]", ...) are
given as examples. In another, the example can overwrite an array.
Others use sentinel values which I don't think of a good practise.

Even good book can have errors, but these just look like bad teaching
examples to me.

 

[CBFalconer]

Are you serious about this? Before you answer that first question, I
would just want you to know, those course books are from OUHK
(Open University of Hong Kong, that's where I currently study about
this) taken from the course code MT258.

Yes, I am serious. I don't know what we want to set him right
about, since you snipped that portion. However I vaguely remember
writing the above, although you snipped the attributions. Please
don't do that. I guess snipping is an acquired art.

We all have an interest in not having bad teachers go uncorrected.
They produce bad product, and make life harder for all of us
correcting those ex-students. Some of us will be more diplomatic
than others, and some will be outright rude.

I suspect if you, as a student, go to your instructor and insist
that he cease and desist from misinformation, it will adversely
affect your marks. However if peers tell him the same, usually
with bell, book, candle, and standards references in hand, s/he may
listen and no evil retribution will fall on you.

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell.org/google/>
Also see <http://www.safalra.com/special/googlegroupsreply/>

 

[Joe Wright]

Yes, I am serious. I don't know what we want to set him right
about, since you snipped that portion. However I vaguely remember
writing the above, although you snipped the attributions. Please
don't do that. I guess snipping is an acquired art.

We all have an interest in not having bad teachers go uncorrected.
They produce bad product, and make life harder for all of us
correcting those ex-students. Some of us will be more diplomatic
than others, and some will be outright rude.

I suspect if you, as a student, go to your instructor and insist
that he cease and desist from misinformation, it will adversely
affect your marks. However if peers tell him the same, usually
with bell, book, candle, and standards references in hand, s/he may
listen and no evil retribution will fall on you.

In my own experience, the young student who demands the instructor cease
and desist from anything at all, will lose big time. If student finds
instructor incompetent, student should change instructors. No student
has ever won the fight with the instructor, in my experience.

 

[jaysome]

Argento said:




Nevertheless, it is incorrect. And now you *know* it's incorrect.

I know for certain that at least one regular contributor to this group, and
possibly more than one, has got into the habit of completely ignoring any
"plea-for-help" article in which the questioner has used void main, on the
grounds that they can't be all that serious about C if they can't even get
the entry point right.

Is "void main" really that bad?

Does anyone have any statistics on the compilers that "void main" causes
problems with?

I suspect that such statistics would show that the use of "void main"
has similar ramifications to tearing off the tag of a bed mattress. If
anyone can prove me wrong, please back it up with some numbers.

 

[Vladimir S. Oka]

Is "void main" really that bad?

Does anyone have any statistics on the compilers that "void main"
causes problems with?

I suspect that such statistics would show that the use of "void main"
has similar ramifications to tearing off the tag of a bed mattress. If
anyone can prove me wrong, please back it up with some numbers.

I don't think `void main()` will really do any nasty things to you.
However, most examples come from posters who are obviously new and
inexperienced, and I believe it signifies either bad teaching they've
been exposed to or not really caring about learning proper C. Something
along the lines of not capitalising `i`s and sentences, and using `u`,
`ur` and similar contractions.

Ask any of them about whether their particular implementation actually
allows `void main()`, which it can if it documents it, they wouldn't
have a clue what you're talking about. And of course, even if it did,
it wouldn't be portable, Standard C, and so would be off-topic here.

 

[Keith Thompson]

Is "void main" really that bad?
Yes.

Does anyone have any statistics on the compilers that "void main"
causes problems with?

I don't know, but that's not really the point.

I suspect that such statistics would show that the use of "void main"
has similar ramifications to tearing off the tag of a bed mattress. If
anyone can prove me wrong, please back it up with some numbers.

There is quite simply no reason to use "void main". Unless you happen
to be using an implementation that (unwisely, IMHO) documents the use
of "void main" as an extension, using it invokes undefined behavior.
Most likely it will work as expected; the worst *likely* problem is
that the program will return an unpredictable exit status to the
environment (which is a good enough reason in itself to avoid it).
But it also means that any time your program doesn't behave as you
expected, you can't be certain that your use of "void main" didn't
cause the problem.

Consistently using the *correct* form costs nothing, and it means you
always have one less thing to worry about.

"void main" *probably* won't cause any real problems, but unless
you're using random numbers, programming isn't about probabilities.
It's about writing correct code that does what you want it to do.

 

[Richard Heathfield]

jaysome said:

Is "void main" really that bad?

Yes, for the reason I gave above.

It's called "cargo cult" programming. Setting aside freestanding
implementations for a moment, there is never a good reason to use void
main. So where does it come from? Not from thinking, that's for sure. No,
people use it because they've seen other people using it, without thinking
of the possibility that those they emulate may not be all that great at C
themselves. Computers copy stuff blindly about the place without
understanding it. People are supposed to be brighter than that.

Does anyone have any statistics on the compilers that "void main" causes
problems with?

Does anyone have statistics on the number of programs that have failed
because of undefined behaviour?

I suspect that such statistics would show that the use of "void main"
has similar ramifications to tearing off the tag of a bed mattress. If
anyone can prove me wrong, please back it up with some numbers.

I suspect that statistics would show that those who don't care enough about
correctness to get the entry point right are also likely not to care enough
about getting other things right. So why bother trying to teach them? Just
let them guess and hope.

 

[Charles Krug]

jaysome said:


Yes, for the reason I gave above.

It's called "cargo cult" programming. Setting aside freestanding
implementations for a moment, there is never a good reason to use void
main.

My entire career is freestanding implementations or things like vxWorks
where you just don't use main() at all.

Why?

Requirments for those types of things often state "ANSI (or ISO) C, with
no extensions," "No warnings from the compiler set at its most stringent
level," and "No unreachable code"

Defining main() void or with the wrong parameters violates the first
requirement (non-ANSI).

Ignoring the warning from main() not returning violates the Second
requirement (causes warnings).

Sticking a return; after a never exits loop violates the third
(unreachable code).

While there exist freestanding, as well as hosted, implementations where
it works, there's rather an enormous gulf between:

"This works on this version of the compiler running under this
processor on this OS cross-compiling to that processor under that OS"

and:

"This is Standard and supported by any conforming implementation."

 

[Ben Bacarisse]

No student has
ever won the fight with the instructor, in my experience.

That may be true, but there should be no fight in the first place. Good
instructors know they can make mistakes and learn from them (rather more
students think they know better that actually do, but that should be no
excuse). To swing back almost OT, I once presented something rather like
this:

int order2(int *a, int *b)
{
if (*a > *b) {
int tmp = *a; *a = *b; *b = tmp;
return 1;
}
return 0;
}

int order4(int *a, int *b, int *c, int *d)
{
int swaps = 0;
while (order2(a, b) || order2(b, c) || order2(c, d))
swaps++;
return swaps;
}

and asked for an informal argument about the termination of the loop in
order4. It was not actually C, but no matter. Most were doing what I
wanted (informally showing that the loop terminates) and getting good
grades for that part until someone pointed out what will happen with
aliased pointers. Obvious enough, maybe, but I was thinking about other
matters when writing the assignment. The next year, the question was
better and asked for two arguments -- including one for when the pointers
might be aliased!

I would be wary of any teacher who does not learn from their students.

 

[Chris Torek]

My entire career is freestanding implementations or things like vxWorks
where you just don't use main() at all.

Of course, if you do not use a main() at all, there is no need to
concern yourself with the return-type and parameter(s) to main().

I actually prefer avoiding main() entirely in freestanding code,
for this reason.

(Also: although it is off topic, I will mention that as of 6.x, vxWorks
does use "main" functions in RTPs.)

 

[Argento]

Yes, I am serious. I don't know what we want to set him right
about, since you snipped that portion. However I vaguely remember
writing the above, although you snipped the attributions. Please
don't do that. I guess snipping is an acquired art.

I am sorry about that. Please accept my apology. As i said in the other
post,
The rules in posting is rather different then those of the newsgroup that i
used
to visit. Guess I still have lots to learn about posting in newsgroup and in
deciding
what to snip. The local newsgroup i used to visit do top-posting, quote the
whole thing,etc.
And I have been reading and learning the rules from what you guys had posted
for the last month. Especially those links about google's broken reply, etc.
I
didn't even know what top posting was at the start

We all have an interest in not having bad teachers go uncorrected.
They produce bad product, and make life harder for all of us
correcting those ex-students. Some of us will be more diplomatic
than others, and some will be outright rude.

I suspect if you, as a student, go to your instructor and insist
that he cease and desist from misinformation, it will adversely
affect your marks. However if peers tell him the same, usually
with bell, book, candle, and standards references in hand, s/he may
listen and no evil retribution will fall on you.

Actually not, I had once did that in my U123 course. The instructor hated me
but
fortunately, it didn't affect my mark. They were even teaching HTML &
javascript
wrongly

Quoted from :-
http://learn.ouhk.edu.hk/~mt258/mt258guest/CourseMT258Frame.htm
"The principles used in the Project have been refined and applied to the
development of the course units.
The course units are internally OUHK developed by Dr. Reggie Kwan, a
previous course coordinator
of this course, and Dr. Andrew Lui, the present course coordinator."

And all I have is the present CC's e-mail (e-mail address removed)
I hope you'll find it useful.

 

[Argento]

Can I watch them burn? ;-)

Only if you are willing to pay part of the cost for buying the book.
It cost me heaps you know. It's course material after all, buying is
compulsory (actually, its accounted into the course fee itself).

 

[Arndt Jonasson]

I have observed compilers sometimes complain that the implicit return
of a function was not reachable when the function ended with exit()...
even in some very straight forward cases.

Yes, that was the situation I had in mind. Perhaps this reason for
my habit is entirely historical by now.

 

[Jordan Abel]

Well, i just keep on seeing examples that uses fflush( stdin ) and i
was told to do so after a scanf() and before a getchar()
because the '\n' is not taken by scanf("%d") or scanf("%c"). That was
my practice of clearing the stdin's buffer.
Any suggestion/alternative of doing so would be appreciated.

Loop getchar() until you see the '\n'.

Though, scanf() itself can be quite capricious and you would do well to
find an alternative to _that_ instead of working around one of its many
apparent and real flaws.

 

[CBFalconer]

Loop getchar() until you see the '\n'.

Not good enough. Have the following routine handy:

#include <stdio.h>

int flushln(FILE *f) {
int ch;

while (('\n' != (ch = getc(f))) && (EOF != ch)) continue;
return ch;
}

--
Some informative links:
< <http://www.geocities.com/nnqweb/>
<http://www.catb.org/~esr/faqs/smart-questions.html>
<http://www.caliburn.nl/topposting.html>
<http://www.netmeister.org/news/learn2quote.html>
<http://cfaj.freeshell.org/google/>

 

[Richard Heathfield]

CBFalconer said:

Not good enough. Have the following routine handy:

#include <stdio.h>

int flushln(FILE *f) {
int ch;

while (('\n' != (ch = getc(f))) && (EOF != ch)) continue;
return ch;
}

Not good enough. Have the following changes ready:

s/flushln/discardln/

(or something along those lines), and either:

s/n ch/n ch == EOF/

or:

s/n ch/n ch != EOF/

The routine is the more useful if its return value can be used in a simple
on/off test in a loop - which you pick is a matter of taste, really. Hence
the second change. The first change is because we really, really, really
mustn't enshrine this ridiculous use of the word "flush" to describe
getting rid of *input*!

 

[Christopher Layne]

The routine is the more useful if its return value can be used in a simple
on/off test in a loop - which you pick is a matter of taste, really. Hence
the second change. The first change is because we really, really, really
mustn't enshrine this ridiculous use of the word "flush" to describe
getting rid of *input*!

Richard 'discards' his toilet.

 

[Richard Heathfield]

Christopher Layne said:

Richard 'discards' his toilet.

No, Richard regards the contents of the toilet bowl as output, so the word
"flush" is appropriate.

But you don't flush a tap (or, if you are Usanian, a faucet).

 

[CBFalconer]

Christopher Layne said:

No, Richard regards the contents of the toilet bowl as output,
so the word "flush" is appropriate.

But you don't flush a tap (or, if you are Usanian, a faucet).

But you do flush an IV. Having had them on and off for the past 3
months I am now an expert.

--
Some informative links:
< <http://www.geocities.com/nnqweb/>
<http://www.catb.org/~esr/faqs/smart-questions.html>
<http://www.caliburn.nl/topposting.html>
<http://www.netmeister.org/news/learn2quote.html>
<http://cfaj.freeshell.org/google/>

 

[Richard Heathfield]

CBFalconer said:

But you do flush an IV.

Yes, but what does an IV do? It carries a fluid from a reserve store,
through the tube, through the needle, and into the destination storage unit
(known as a "patient"). Thus, flushing an IV - which is done to ensure that
all the fluid intended to be administered has indeed been administered,
just as fflush is done to ensure that all the data we intend to write to
the disk is indeed written - is an *output* operation.

Having had them on and off for the past 3
months I am now an expert.

I am sorry to hear that.