lint (was: Funny mistake)

D'Arcy J.M. Cain darcy at druid.uucp
Fri Mar 29 00:52:30 AEST 1991


In article <c48H01l04bKM00 at amdahl.uts.amdahl.com> Duane Richard LaMont writes:
>In article <1991Mar24.165719.26908 at druid.uucp> darcy at druid.uucp (D'Arcy J.M. Cain) writes:
>>Just a side note here.  I hardly ever prototype static functions.  I
>I thought this was a good idea too, but it didn't work for me on the
>first prototyping compiler I ever used (SCO XENIX, forget the version

Of course I did mean ANSI compilers.

> [...]
>comfortable with.  Of course, this discussion wouldn't be complete without
>mentioning mutual recursion.  I'm sure that's one case where Mr. Cain does
                                                              ^^^^^^^^
     You mean my father agrees with me too? ----------------------^

>prototype static functions (note he didn't say "never" :-).
>
>Are prototyping compilers supposed to treat a function as prototyped
>following that function's definition?

K&R2 pp 72 says:
  "The function atof must be declared and defined consistently.  If atof
  itself and the call to it in main have inconsistent types in the same
  source file, the error will be detected by the compiler.  But (as is
  more likely) atof were compiled separately ..."

It goes on to discuss the situation where it has to determine the parameters
to atof by other rules when atof is not defined in the current file.  This
would strongly suggest that the answer is yes.  In fact you would almost
think that the order of calls and definitions is immaterial except for the
following sentence from the paragraph following the one above:

  "... a function is implicitly declared by its first appearance in an
  expression ..."                               ^^^^^

So the following:

  ...
  foo(5);
  ...
}
void foo(long i)
{
  ...

If handled the "right way" i.e. an extra pass to determine the type of
argument to foo before compiling the call to it would not be fully conforming.

-- 
D'Arcy J.M. Cain (darcy at druid)     |
D'Arcy Cain Consulting             |   There's no government
Toronto, Ontario, Canada           |   like no government!
+1 416 424 2871                    |



More information about the Comp.lang.c mailing list