Mail Archives: djgpp/1996/09/14/15:21:14
Chris Waters wrote:
>
> In article <3238BAD4 DOT A45980C AT alcyone DOT com>,
> Erik Max Francis <max AT alcyone DOT com> wrote:
> >Presently, traditional-style function declarations are still supported in ANSI
>
> After a fashion--you may have unexpected conversions of char or short to
> int and float to double, however. And they are deprecated. And the
> standard is currently in review--this might disappear as soon as next
> year (though I grant it's unlikely).
The only reason "traditional" declarations are supported in ANSI is for
compatibility reasons. The whole reason for changing them in the first
place is that the old-style function declarations provide NO WAY for the
compiler to verify that the correct number and type of arguments are
being passed to a function! The only place that is possible is in the
same source file as the given function, AFTER the definition. Elsewhere
you are pretty much taking your chances, and you'll never know it until
the program bombs.
> Technically (as long as we're being language lawyers), it is, in fact,
> illegal to declare it here. In fact, this may simply fail on Borland C
> for OS/2, where some standard library functions are declared with a
> "pascal" interface. Yes, Borland *is* allowed to do that by the standard.
Not to mention that it's just plain dumb to redeclare a standard function,
when the definition is already available. It's also bad for portability,
as who's to say that the standard definition might not change tomorrow?
The whole point of declaring things in headers is to keep this sort of
clutter out of the programs themselves.
> >There's nothing wrong with using exit to terminate a program, even if you're
> >in main.
>
> But an integer function should return an integer. Therefore, you would
> have to use:
>
> #include <stdlib.h> /* or do I mean stddef.h? */
Stdlib is where exit() is declared (under GNU, at least).
> int main()
> {
> /* blah blah blah... */
> exit (0);
> return 0;
> }
>
> Which is redundant and silly. :)
Plus, if you compile with strict attention to program flow, you will
probably get warnings from the compiler that the 'return' will never
be reached. :) At least, I have had Turbo C do such things to me;
gcc doesn't seem to care unless I tell it specifically to do so.
After all, exit() is declared 'noreturn'.
> Note also that exit(), technically, requires one of the standard headers
> to be included; return does not.
Which, by common sense, makes it a less suitable solution to the
problem, which is, to be blunt, just plain laziness. :) Lemme see
here...
== LAZINESS SCALE COMPARISON OF void main()/exit WITH int main/return ==
NOTE: the following assumes the writing of the absolute mininum program
which will compile WITHOUT ANY WARNINGS with -Wall, and will perform
correctly with NO POSSIBILITY of unexpected behavior.
=== void main/exit: Characters to type ===
#include <stdlib.h> 19
void main() 11
exit(0); 8
=== TOTAL characters: 38
=== int main()/return: Characters to type ===
int main() 10
return 0; 9
=== TOTAL characters: 19
Therefore, it can be conclusively demonstrated that using the void
main() construct requires MORE WORK than using int main(void) and a
return. In fact, even if you discard the <stdlib.h> include, you
still end up typing the EXACT SAME number of characters!
Hopefully, this should dispel this pathetic argument once and for
all. :)
--
John M. Aldrich, aka Fighteer I <fighteer AT cs DOT com>
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS d- s+:- a-->? c++>$ U@>++$ p>+ L>++ E>+ W++ N++ o+ K? w(---) O-
M-- V? PS+ PE Y+ PGP- t+(-) 5- X- R+ tv+() b+++ DI++ D++ G e(*)>++++
h!() !r !y+()
------END GEEK CODE BLOCK------
- Raw text -