Warren W. Gay VE3WWG <ve3wwg@cogeco.ca> wrote :
> Jean-Pierre Rosen wrote:
> > "Eric G. Miller" <egm2.NOSPAM@jps-NOSPAM.net> a �crit dans le message news:
IpfQ9.4953
...
> >>You're right, but I'm sure gcc could have immediately diagnosed the
> >>problem had you turned up the warnings ("conflicting types for...",
"previous
> >>declaration of ...").
> >
> > Warnings were on, he just overlooked them....

Could have (and did) *IF* the same declaration is visible at
all relevant locations, typically by #include'ing the same .h file.
If you just write out a wrong declaration of foo in bar.c, gcc can't
catch it (though a good lint can).  Also, if you mistakenly #include
a wrong .h file (such as from a wrong subtree) gcc can't catch it,
although this is unlikely in simple student projects.
(A C implementation *could* legally and practially do
the kinds of whole-program or at least cross-unit checks
Ada requires and GNAT does, but they don't, not even gcc.)

...
> Things may be different now, but I once had a long email discussion
> with one of the folks about whether a missing return "type" should
> be a warning or not (it should actually be an error). At the time,
> you had to specify a compile option to make a declaration like:
>
> foo() { ... }
>
> return a warning. ...

(That's a definition, not just a declaration.
/*int*/ foo () ; is a typical "external" declaration.)

According to all C standards before C99 (K&R and C89) it *is*
legal and so can't conformingly be an error.  With C99 it is a
required diagnostic and could well be an error, but won't because
implementors don't want to break vast masses of existing legal
and supported code.  I agree it should be a warning, but whether
it's on by default doesn't matter much to me, since I always end up
with some mechanism (makefile, script, envvar) for setting flags
anyway, and if this needs an entry in there it's no real trouble.

--
- David.Thompson 1 now at worldnet.att.net