🚀 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

On 16 Apr 1996 21:41:21 -0600 in article </REdxQ9ytt2Y089yn@csn.net>
    thads@csn.net (Thad Smith) (Thad Smith) wrote:

>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.

<snip>

>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.

Most modern compilers, as far as I have seen, provide a (suppressible) warning
in this situation.  It could be viewed as a quality-of-implementation issue.

--
Peter Curran                               pcurran@inforamp.net

In article <829573502snz@wbriscoe.demon.co.uk>, walter briscoe <walter@wbriscoe.demon.co.uk> writes:
>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.

This was not K&R code.  In K&R code, there was no "void" type so all
functions had to have some return type (defaulting to int) but just didn't
have to return a value if no return value was expected.  In K&R code, if a
value was not returned by a return statement, then no value was returned.
There was no implicit return value 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.
>> [...]  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.

At the time of executing the called function, if the implementation can
determine that the caller will necessarily attempt to use a value which
the called function is not returning, then the implementation is free
to exhibit undefined behavior at that point.  An example of undefined
behavior could be to continue executing what the program specifies until
the point where the caller attempts to use a value which the called
function did not return, and then take some unpredictable action.
So if you get the change you're asking for, how will you even know?

>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.

Don't forget to add:
 The statement preceding the } that terminates a function whose return
 type is not void shall be one of these forms:
 o   a return statement,
 o   a goto statement,
 o   an if statement with else clause in which each sub-statement is
      one of these forms, or
 o   a switch statement in which the sub-statement contains a
      sub-sub-statement with the label label default and every
      sub-sub-statement is one of these forms, or
 o   a compound statement in which the last sub-statement is one
      of these forms.
 
>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.

You mean because less unreasonable K&R code always used the redundant
type specifier "int" to declare functions that returned int when they
really intended to return int?  As it happens, I agree with you that this
kind of coding style is good practice for readability and maintainability,
and resent having to fight against a language in order to practice such
noble ideals.  However, your real request is to use a language other than
C.  Again I agree, most programs should not use C.

>I would have implicitly typed declarations deprecated in the next
>revision of the standard to facilitate their removal by a further revision.

Put it in a standard for a different language.  You probably know a dozen
that have this feature.
--
 <<  If this were the company's opinion, I would not be allowed to post it.  >>
"I paid money for this car, I pay taxes for vehicle registration and a driver's
license, so I can drive in any lane I want, and no innocent victim gets to call
the cops just 'cause the lane's not goin' the same direction as me" - J Spammer

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.
... 
: 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.
Several years ago I ran into more than one instance of code that relied
on (some unspecified C compiler) that would return the last declared
variable if no return-value was given -- I assume the committe had that
one in mind, e.g.,

	int foo()
	{
		int x = 4;
		return;	/* implictly returns 4 */
	}

(of course I eradicated it from the code, but it would be interesting
to know whose compiler it was written for ;-)

-- 
Thomas E. Dickey
dickey@clark.net