🚀 go-pugleaf

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.

The Rationale, I have, associated with a draft of the standard makes no
comment on the return statement.

I would like the next version of the standard to have an additional
constraint:
A return statement without an expression shall only appear in a function
whose return type is void.
causing the redundancy of:
> 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.

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 would have implicitly typed
declarations deprecated in the next revision of the standard to
facilitate their removal by a further revision.
--
walter briscoe