void main() (where did this come from)???
SpectreV
Thank-you again to those of you who have helped me in the past. While I
am a student, I also tutor C programming and wonder where the void main() got
started. It's even included in several of the texts that are used at my
school. I was fortunate that someone pointed this out to me as being less than
desireable when I first started but I find myself repeating it to every student
I see and not really having a good argument to counter all the examples that
are in the textbook other than if you use it your code won't be cross platform
compatible which most of the beginners don't seem to care about anyway.
Thanks!
Vaughn
--
comp.lang.c.moderated - moderation address: cl...@plethora.net
Erik Max Francis
> Thank-you again to those of you who have helped me in the past.
> While I
> am a student, I also tutor C programming and wonder where the void
> main() got
> started. It's even included in several of the texts that are used at
> my
> school.
My guess that someone writing C programs -- particularly in an
environment that pays little attention to the return value of main --
just figured, "Hey, I'm not going to be doing anything with the exit
value the program returns, so I'll just declare main as returning void
and not worry about it."
> I was fortunate that someone pointed this out to me as being
> less than
> desireable when I first started but I find myself repeating it to
> every student
> I see and not really having a good argument to counter all the
> examples that
> are in the textbook other than if you use it your code won't be cross
> platform
> compatible which most of the beginners don't seem to care about
> anyway.
The best argument against it is that it is nonstandard C. If you define
main to return void, then you are entering the realm of undefined
behavior. This could conceivably include crashing, erasing your hard
disks, or emailing your boss the message, "One of your programmers does
not know Standard C."
--
Erik Max Francis | email m...@alcyone.com | icq 16063900
Alcyone Systems | web http://www.alcyone.com/max/ | q3a Product
San Jose, CA | languages en, eo | icbm 37 20 07 N 121 53 38 W
USA | 967.342 Ms p.L. | 291 days left | &tSftDotIotE
__
/ \ They have rights who dare defend them.
\__/ Roger Baldwin
Chris Mears
Thu, 16 Mar 2000 04:57:12 GMT, he wrote:
>Greetings.
>
> Thank-you again to those of you who have helped me in the past. While I
>am a student, I also tutor C programming and wonder where the void main() got
>started. It's even included in several of the texts that are used at my
>school. I was fortunate that someone pointed this out to me as being less than
>desireable when I first started but I find myself repeating it to every student
>I see and not really having a good argument to counter all the examples that
>are in the textbook other than if you use it your code won't be cross platform
>compatible which most of the beginners don't seem to care about anyway.
Tell them, straight out, that void main() is wrong. If they challenge
you, look them in the eye and say it again. "void main() is wrong."
When they point to their textbooks, tell them the textbooks are wrong,
and that you are right. Chances are they will not appreciate this.
They will challenge you once more. Find a copy of the C Standard, and
show it to them. Afterwards, hit them over the head with it.
HTH
--
Chris Mears
chris...@softhome.net
ICQ: 36697123
C-FAQ: http://www.eskimo.com/~scs/C-faq/top.html
Juergen Ilse
SpectreV <spec...@aol.com> wrote:
> Thank-you again to those of you who have helped me in the past. While I
> am a student, I also tutor C programming and wonder where the void main() got
> started. It's even included in several of the texts that are used at my
> school. I was fortunate that someone pointed this out to me as being less than
> desireable when I first started but I find myself repeating it to every student
> I see and not really having a good argument to counter all the examples that
> are in the textbook other than if you use it your code won't be cross platform
> compatible which most of the beginners don't seem to care about anyway.
"void main()" is not covered by the standard (if you use a hosted Environment,
which i assume), "void main()" leads to "undefined behaviour", even if it is
working in most cases. "main()" has (according to the standard) to return
something of type "int", where a return-value of 0 or EXIT_SUCCESS (defined
in stdlib.h) means "successful execution" und EXIT_FAILURE means "unsuccessful
execution". The meanings of all other possible return-values of main() are
"implementation defined".
ciao,
Juergen Ilse (il...@asys-h.de)
--
Eingedeutschte Fehlermeldungen sind doch etwas | Juergen Ilse
schoenes: "Gefahr einer Systemverklemmung" | Internet POP Hannover
statt "EDEADLK" in SINIX 1.0B | Vahrenwalder Str. 205
-----------------------------------------------------| 30165 Hannover
Neu in de.comp.os.unix.linux.*? Lies die infos-Gruppe| il...@pop-hannover.net
Francis Glassborow
<spec...@aol.com> writes
> Thank-you again to those of you who have helped me in the past. While I
>am a student, I also tutor C programming and wonder where the void main() got
>started. It's even included in several of the texts that are used at my
>school. I was fortunate that someone pointed this out to me as being less than
>desireable when I first started but I find myself repeating it to every student
>I see and not really having a good argument to counter all the examples that
>are in the textbook other than if you use it your code won't be cross platform
>compatible which most of the beginners don't seem to care about anyway.
I think it got started when a certain compiler implementor found that
supporting it cut enquiries to their help-line. In the early K&R days
there was no such thing as void but failure to provide a return
statement was OK as long as no attempt was made to use the return value.
ISO C placed stricter requirements which broke a lot of legacy code in
the specific case of main(). C++ fixed that for itself by making a
special rule for main() that falling out of it was deemed to be
equivalent to return 0. That is fine for C++ where main is special (it
cannot be called and so exit from main is always the end of the program)
but in C main is just an ordinary function that can be called
recursively.
The best answer to students is that the function exit() is always called
for normal termination of a C program, either explicitly or implicitly
[by return from main()]. exit() needs an argument which must either be
provided explicitly or implicitly. Standard C does not provide a
mechanism to provide this value implicitly but those supporting void
main() do so as an extension, a pity because the better extension would
have been C++'s implicit '0'
Francis Glassborow Journal Editor, Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA +44(0)1865 246490
All opinions are mine and do not represent those of any organisation
Hans-Bernhard Broeker
> Thank-you again to those of you who have helped me in the past.
> While I am a student, I also tutor C programming and wonder where
> the void main() got started. It's even included in several of the
> texts that are used at my school.
Let that serve as your personal reminder that just because someone put
something into a book, that alone doesn't lend it much credibility,
any more. Not these days, and especially not in the field of
computing.
[...]
> your code won't be cross platform compatible which most of the
> beginners don't seem to care about anyway.
This lack of care is *exactly* the root of the problem. It's also
called 'tunnel vision', sometimes: while working on a problem
perceived to be small, people tend to neglect to look anywhere else
than straight ahead. That's how they get into such bad habits as the
'void main()' culture, or the 'cast the return value of malloc()' one.
It seems to work, so they never look back or sideways to see if it's a
good way to do it. Sooner or later, they begin to think of it as 'the'
way of doing it.
Next time when anyone asks you about a reason *not* to void main(),
turn the question back on him: what reason can he give in favour of
it, given that there *is* a standard that requires int main()? You
don't usually need a reason for complying to a rule, but to be
breaking it, your opponent should be able to give a reason. You'll
find they don't have any non-ridiculous argument at all.
--
Hans-Bernhard Broeker (bro...@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.
Dan Pop
> Thank-you again to those of you who have helped me in the past. While I
>am a student, I also tutor C programming and wonder where the void main() got
>started.
Most likely it started like that:
#include <stdio.h>
main()
{
printf("hello, world\n");
}
The compiler warns that main() is defined as returning an int, but it
doesn't return anything. There are two ways to shut it up:
1. Define main() as a void function.
2. Add a return statement.
The innocent newbie programmer has to make a choice. He'll make the
wrong one. In time, he'll become an experienced programmer, but he'll
keep the bad habit acquired in his early C days.
The program above is a verbatim reproduction of the first C code
example in K&R2. One of the most popular compilers of ten years ago,
Turbo C (later Borland C) used to emit that warning at the default
warning level.
Dan
--
Dan Pop
CERN, IT Division
Email: Dan...@cern.ch
Mail: CERN - IT, Bat. 31 1-014, CH-1211 Geneve 23, Switzerland
Oliver Walter
> Thank-you again to those of you who have helped me in the past. While I
> am a student, I also tutor C programming and wonder where the void main() got
> desireable when I first started but I find myself repeating it to every student
> I see and not really having a good argument to counter all the examples that
> compatible which most of the beginners don't seem to care about anyway.
As far as I can see it's partly the fault of K&R (Kernighan & Ritchie
2nd ed.). Although it has been stated many times in this Newsgroup that
main returns an int value, K&R, allegedly a good book for learning ANSI
C, does not state this fact.
See, for example. pages 6, 26, 115, 164 and 171. These are all
places where you would expect "int main(..." but instead they
all say only "main(...". Page 26 gets somewhere near by saying
"Since main is a function like any other, it may return a value
to its caller, which is in effect the environment in which the
program was executed.... programs should return status to their
environment." but even here it doesn't say that it is an int value.
Is it possible that this fact about main had not been decided at
the time this book was written?
--
Oliver Walter, speaking for myself, not my employer
Alenia Marconi Systems Ltd
Borehamwood, UK
Real email address (with obvious interpretation):
oliver (DOT) walter (AT) gecm (DOT) com
Douglas A. Gwyn
> Is it possible that this fact about main had not been decided at
No, it was known and appreciated by the authors that the shape
of the "main" function was necessarily int main(int,char**).
I remarked about this when reviewing a draft of the book,
and the upshot was that for pedagogical reasons the first few
example programs wouldn't be too fussy about returning a status
value, but that would be introduced later in the book. Note
that K&R does *not* define main as having void return; the lack
of explicit "int" still implies a return type of "int". (Only
in C99 was implicit "int" finally deprecated.) The only real
flaw in regard to the interface in the early examples is that
no value is returned from the main function, which means in
nearly every actual implementation, a "garbage" value is the
status reported to the environment. At worst, that means a
spurious "program reported failure" message after the program
finishes execution; but most often, the status isn't being
used anyway, so its omission was benign.
Francis Glassborow
<noj...@gecm.com> writes
>Is it possible that this fact about main had not been decided at
It wasn't even of importance when the 1st edition was written and I
think it just slipped through when the second edition was being
prepared.
>
Francis Glassborow Journal Editor, Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA +44(0)1865 246490
All opinions are mine and do not represent those of any organisation
Francis Glassborow
<chris...@softhome.net> writes
>Tell them, straight out, that void main() is wrong. If they challenge
>you, look them in the eye and say it again. "void main() is wrong."
>When they point to their textbooks, tell them the textbooks are wrong,
>and that you are right. Chances are they will not appreciate this.
>They will challenge you once more. Find a copy of the C Standard, and
>show it to them. Afterwards, hit them over the head with it.
It is very useful for students to learn early on that neither text books
nor instructors are always right:) Then they have the problem of
deciding who to trust:)
Francis Glassborow
<bro...@acp3bf.physik.rwth-aachen.de> writes
>That's how they get into such bad habits as the
>'void main()' culture, or the 'cast the return value of malloc()' one.
But you need to be careful. void main() is 'wrong' in all hosted
environments. OTOH casting malloc is necessary for C++ source code.
Yes, I write both C and C++ and understand why it is different in the
two and it isn't simply that one language is right and the other wrong.
Chris Mears
where his towel is. On Sat, 18 Mar 2000 05:48:32 GMT, he wrote:
>In article <clcm-2000...@plethora.net>, Chris Mears
><chris...@softhome.net> writes
>>Tell them, straight out, that void main() is wrong. If they challenge
>>you, look them in the eye and say it again. "void main() is wrong."
>>When they point to their textbooks, tell them the textbooks are wrong,
>>and that you are right. Chances are they will not appreciate this.
>>They will challenge you once more. Find a copy of the C Standard, and
>>show it to them. Afterwards, hit them over the head with it.
>
>It is very useful for students to learn early on that neither text books
>nor instructors are always right:) Then they have the problem of
>deciding who to trust:)
You trust the people on Usenet. After all, the Internet is always
right... isn't it?
--
Chris Mears
chris...@softhome.net
ICQ: 36697123
C-FAQ: http://www.eskimo.com/~scs/C-faq/top.html
Ariel Scolnicov
> In article <clcm-2000...@plethora.net>, Oliver Walter
> <noj...@gecm.com> writes
> >Is it possible that this fact about main had not been decided at
> >the time this book was written?
>
> It wasn't even of importance when the 1st edition was written and I
> think it just slipped through when the second edition was being
> prepared.
Perhaps this should be explained: 1st edition didn't have `void'; main
is commonly defined as "main()" (see, e.g., p. 6).
--
Ariel Scolnicov |"GCAAGAATTGAACTGTAG" |ari...@compugen.co.il
Compugen Ltd. |Tel: +972-2-6795059 (Jerusalem) \ We recycle all our Hz
72 Pinhas Rosen St. |Tel: +972-3-7658514 (Main office)`---------------------
Tel-Aviv 69512, ISRAEL |Fax: +972-3-7658555 http://3w.compugen.co.il/~ariels
SpectreV
>is commonly defined as "main()" (see, e.g., p. 6).
Correct, but my understanding is that the standard defines main() as having the
return type of int. Perhaps this was why they didn't explicitly state it.
Then somewhere along the way the void main() thing got started.
By the way, I just purchased a copy of K&R and am enjoying it tremendously.
Vaughn
Da Silva Costa, O.R.
I agree with most of what you say, but at some stage you say:
> than straight ahead. That's how they get into such bad habits as the
> 'void main()' culture, or the 'cast the return value of malloc()' one.
> It seems to work, so they never look back or sideways to see if it's a
> good way to do it. Sooner or later, they begin to think of it as 'the'
> way of doing it.
So, is it a bad habit to cast the return value of malloc? In K&R2, page
142, it is said: "The question of type declaration for a function like
malloc is a vexing one for any language that takes its type-checking
seriously. In C, the proper method is to declare that malloc returns a
pointer to void, then explicity coerce the pointer into desired type
with a cast."
I would like to know your opinion about this.
Thanks in advance,
Orlando.
Da Silva Costa, O.R.
Philips Research Laboratories - Building WL1.1.25
Prof. Holstlaan 4
5656 AA Eindhoven
The Netherlands
Phone: +31-40-2743498
E-mail: das...@natlab.research.philips.com
Ben Pfaff
> So, is it a bad habit to cast the return value of malloc?
Yes.
> In K&R2, page 142, it is said: "The question of type
> declaration for a function like malloc is a vexing one for any
> language that takes its type-checking seriously. In C, the
> proper method is to declare that malloc returns a pointer to
> void, then explicity coerce the pointer into desired type with
> a cast."
They were <gasp!> wrong. K&R2 was written, AIUI, against a late
draft of C89 or soon after its final release, at which point best
practices weren't yet evident. There is generally a consensus in
these parts that casting the result of malloc is unnecessary and
untoward.
Douglas A. Gwyn
> So, is it a bad habit to cast the return value of malloc? In K&R2, page
> 142, it is said: "The question of type declaration for a function like
> malloc is a vexing one for any language that takes its type-checking
> seriously. In C, the proper method is to declare that malloc returns a
> pointer to void, then explicity coerce the pointer into desired type
> with a cast."
Until 1989, that is essentially what one *had* to do (for portability),
except the generic-pointer type until then was char* rather than void*.
The C standard introduced automatic conversion to/from void* in many
contexts (such as assignment), so it was no longer strictly necessary
for the programmer to explicitly code the cast. There are two schools
of thought on this:
(A) Put the explicit cast:
(1) It makes it more obvious what conversion occurs.
(2) It shows that you thought about the conversion.
(3) It makes that code compatible with C++.
(B) Omit the explicit cast:
(1) It makes for less "verbiage".
(2) It will probably generate a diagnostic if you
forgot to #include <stdlib.h> to get a prototype
of malloc in scope.
We could argue interminably about which is better. You decide.
Oleg Goldshmidt
> So, is it a bad habit to cast the return value of malloc? In K&R2, page
> 142, it is said: "The question of type declaration for a function like
> malloc is a vexing one for any language that takes its type-checking
> seriously. In C, the proper method is to declare that malloc returns a
> pointer to void, then explicity coerce the pointer into desired type
> with a cast."
>
> I would like to know your opinion about this.
FAQ 7.7, also H&S 4th ed. pp 386-387.
In a nutshell, in ANSI C the cast is not necessary. If you need
compatibility with traditional C, you'll cast, to avoid lint warnings.
Or you might want to have a strictly ANSI code that will warn you
that you are in a non-standard environment, then you won't cast.
E.g. without a cast, gcc -traditional will complain, gcc -pedantic
won't. I usually prefer not to cast - if I get a warning I will know
I am not using ANSI-compliant compiler flags (I am supposed to).
--
Oleg Goldshmidt | BLOOMBERG L.P. (BFM) | ol...@bfr.co.il
"... We work by wit, and not by witchcraft;
And wit depends on dilatory time." - W. Shakespeare.
Brian Inglis
<das...@natlab.research.philips.com> wrote:
>Hello!
>I agree with most of what you say, but at some stage you say:
>
>> than straight ahead. That's how they get into such bad habits as the
>> 'void main()' culture, or the 'cast the return value of malloc()' one.
>> It seems to work, so they never look back or sideways to see if it's a
>> good way to do it. Sooner or later, they begin to think of it as 'the'
>> way of doing it.
>
>So, is it a bad habit to cast the return value of malloc? In K&R2, page
>142, it is said: "The question of type declaration for a function like
>malloc is a vexing one for any language that takes its type-checking
>seriously. In C, the proper method is to declare that malloc returns a
>pointer to void, then explicity coerce the pointer into desired type
>with a cast."
>
>I would like to know your opinion about this.
>Thanks in advance,
>Orlando.
K&R2 was based on the draft standard. Casting was necessary
because originally alloc() and then malloc() were defined to
return char*, before some compilers and then the Standard allowed
a void*, and defined it as being convertible to any other object
type. This made the practice of casting unnecessary, and possibly
misleading or wrong, if the pointer type was changed, and the
cast was not. So for maintenance reasons, it is now undesirable
to cast any void*. Casting used to be necessary to keep lint
quiet about pointer types, and could be considered as part of an
AT&T inhouse standard.
Thanks. Take care, Brian Inglis Calgary, Alberta, Canada
--
Brian_...@CSi.com (Brian dot Inglis at SystematicSw dot ab dot ca)
use address above to reply
bro...@physik.rwth-aachen.de
> I agree with most of what you say, but at some stage you say:
>> than straight ahead. That's how they get into such bad habits as the
>> 'void main()' culture, or the 'cast the return value of malloc()' one.
> So, is it a bad habit to cast the return value of malloc?
Sort of. It's mainly a bad habit to believe you *have to* cast
malloc()'s result, because that's simply not true, in a C program.
It's a typical sign of the confusion caused by compilers and books
speaking of the non-existant language 'C/C++'.
Given that you save some extra typing and visual clutter by leaving
out the cast, which will automatically be done implicitly, anyway, and
that religious casting of malloc() results may hide the compiler
warnings you'ld have got when you forget to #include <stdlib.h>,
that's enough reason for me to strongly advise against casting of
malloc() results.
> In K&R2, page
> 142, it is said: "The question of type declaration for a function like
> malloc is a vexing one for any language that takes its type-checking
> seriously. In C, the proper method is to declare that malloc returns a
> pointer to void, then explicity coerce the pointer into desired type
> with a cast."
My personal opinion is that this is one of the very few flaws in the
book.
--
Hans-Bernhard Broeker (bro...@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.
Dan Pop
>So, is it a bad habit to cast the return value of malloc? In K&R2, page
>142, it is said: "The question of type declaration for a function like
>malloc is a vexing one for any language that takes its type-checking
>seriously. In C, the proper method is to declare that malloc returns a
>pointer to void, then explicity coerce the pointer into desired type
>with a cast."
>
>I would like to know your opinion about this.
Ritchie admitted that it was a mistake. Quoting from an article posted
by Greg Black on comp.lang.c on 28 Mar 1995:
To save anybody from the embarrassment of leaping needlessly to the
defence of K&R-2, I asked Dennis Ritchie for an opinion that I could
quote on the validity of the sentence cited above from page 142. He
replied:
In any case, now that I reread the stuff on p. 142, I think it's
wrong; it's written in such a way that it's not just defensive
against earlier rules, it misrepresents the ANSI rules.
Dan
--
Dan Pop
CERN, IT Division
Email: Dan...@cern.ch
Mail: CERN - IT, Bat. 31 1-014, CH-1211 Geneve 23, Switzerland
Oleg Goldshmidt
this thread I opened "Advanced Programming In The UNIX Environment" by
Stevens. A few lines of fine print in Section 7.3, p. 163 explain -
very plausibly, IMHO - where void main() came from. I recalled the
thread that I didn't follow really. I went through it to see if anyone
mentioned this - I think not. Here is the story.
First, main() is a function like any other C function. It is called by
the C startup code. The startup code may be written in assembler, but
if it were written in C, the call to main would look like
exit(main(argc,argv));
Clearly, main has to return an int. The function exit() does some
cleanup (closes i/o streams, flushing the buffered stuff in the
process, etc), and returns control to the kernel via _exit(). You can
call exit() from anywhere in your code, actually, but let's consider
int main(void) { exit(0); }
Imagine a compiler (or lint) that does not know that exit() is special
(modern tools do know that it's OK to call exit()), and thinks it is a
normal function. You'll get a warning such as "control reaches end of
non-void function". After some time, it'll get on your nerves, and you
will look for a way to make your compiler shut up. One way is to use
return. However, according to Stevens, people wanted to grep their
code for *all* calls to exit(). So they used void main() to get rid of
the messages.
Now, Stevens aside, IMHO you need very good reasons to use exit(0)
rather than return (not just in main()). In most application code no
reason will be good enough. And one should never use void main() - you
never know what'll break if you do. I just verified that gcc with all
sorts of warnings (not just -Wall) does not complain about exit() in a
non-void function - curiousity killed the cat.
--
Oleg Goldshmidt | BLOOMBERG L.P. (BFM) | ol...@bfr.co.il
"... We work by wit, and not by witchcraft;
And wit depends on dilatory time." - W. Shakespeare.
Douglas A. Gwyn
> ... However, according to Stevens, people wanted to grep their
> code for *all* calls to exit(). So they used void main() to get rid
> of the messages.
With all due respect to Stevens, I don't think that was widespread
practice in the UNIX community.
Brian B. Rodenborn
>In <clcm-2000...@plethora.net> "Da Silva Costa, O.R." <das...@natlab.research.philips.com> writes:
>
>>So, is it a bad habit to cast the return value of malloc? In K&R2, page
>>142, it is said:
[snip K&R suggesting a cast of malloc()]
>Ritchie admitted that it was a mistake. Quoting from an article posted
>by Greg Black on comp.lang.c on 28 Mar 1995:
>
> In any case, now that I reread the stuff on p. 142, I think it's
> wrong; it's written in such a way that it's not just defensive
> against earlier rules, it misrepresents the ANSI rules.
Yep, he even lists it in the K&R errata section on his web page:
http://www.cs.bell-labs.com/cm/cs/cbook/2ediffs.html
"142: The remark about casting the return value of malloc ("the proper method
is to declare ... then explicitly coerce") needs to be rewritten. The example
is correct and works, but the advice is debatable in the context of the
1988-1989 ANSI/ISO standards. It's not necessary (given that coercion of void *
to ALMOSTANYTYPE * is automatic), and possibly harmful if malloc, or a proxy
for it, fails to be declared as returning void *. The explicit cast can cover
up an unintended error. On the other hand, pre-ANSI, the cast was necessary,
and it is in C++ also.
ka...@gabi-soft.de
|> In article <clcm-2000...@plethora.net>, SpectreV
|> <spec...@aol.com> writes
|> > Thank-you again to those of you who have helped me in the
|> >past. While I am a student, I also tutor C programming and wonder
|> >where the void main() got started. It's even included in several
|> >of the texts that are used at my school. I was fortunate that
|> >someone pointed this out to me as being less than desireable when I
|> >first started but I find myself repeating it to every student I see
|> >and not really having a good argument to counter all the examples
|> >that are in the textbook other than if you use it your code won't
|> >be cross platform compatible which most of the beginners don't seem
|> >to care about anyway.
|> I think it got started when a certain compiler implementor found that
|> supporting it cut enquiries to their help-line. In the early K&R days
|> there was no such thing as void but failure to provide a return
|> statement was OK as long as no attempt was made to use the return value.
|> ISO C placed stricter requirements which broke a lot of legacy code in
|> the specific case of main(). C++ fixed that for itself by making a
|> special rule for main() that falling out of it was deemed to be
|> equivalent to return 0. That is fine for C++ where main is special (it
|> cannot be called and so exit from main is always the end of the program)
|> but in C main is just an ordinary function that can be called
|> recursively.
It's also fine for C, where main is required to return an int, and
falling off the end of a function returning int is undefined behavior,
at least if the value is used. All the rule does is define one very
specific and very limited case of undefined behavior.
Whether it is worth it or not is another question.
--
James Kanze mailto:ka...@gabi-soft.de
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
Ziegelhüttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627