🚀 go-pugleaf

In article <829573502snz@wbriscoe.demon.co.uk>,
walter briscoe <walter@wbriscoe.demon.co.uk> wrote:
>I recently had trouble moving some K&R code to ISO C.
>
>Specifically, a function without a return statement was used to return a
>value with an implicit return at the } terminating the function.
>
>Section 6.6.6.4 of ANSI/ISO 9899-1990 contains the Semantic restriction
>> If a return statement without an expression is executed, and the value
>> of the function call is used by the caller, the behavior is undefined.
>
>It goes on to say:
>> Reaching the } that terminates the function is equivalent to executing
>> a return statement without an expression.
>
>I am surprised/irritated that the undefined behavior is in the caller
>rather than the called function.

It must be so for compatibility with K&R, as you note.

>The obvious objection to such a statement is that it conflicts with
>prior art.  I would answer that by making the implicit type of
>declarations void rather than int.  That would allow less unreasonable
>prior art to port without complaint.  

I haven't worked with much K&R code, so don't know how valid that is.
I suspect that there is lots of legacy code with an implicit int
return type that actually returns values.  My early impression of C
was that much code was designed to be parsimonious.

The following proposal would be somewhat better: if the return type is
explicitly typed, the return statement must provide a value.
Someone will surely trot out some existing working code that violates
this, however.

In the meantime, use a good lint.

Thad