[cfe-dev] C90 conformance: return statements without expressions in non-void functions

[John McCall]

On Sep 14, 2010, at 11:05 AM, Dale Johannesen wrote:
> On Sep 14, 2010, at 8:39 AMPDT, Douglas Gregor wrote:
>>> 
>>> Can any language lawyers comment on whether yfunc() should compile in
>>> C90 mode?
> 
> #if !defined(CPLUSPLUS) && !defined(C99)
> yfunc(i, pfn, pi) /* no return type, default to int */
>   int i;
>   int pfn();  /* parm w fn type becomes ptr-to-fn */
>   int *pi;
> #else
> int yfunc(int i, int pfn(int*), int* pi) /* make yfunc explicit int
> for C++ */
>     /* parm w fn type becomes ptr-to-fn */
> #endif /* CPLUSPLUS */
> { 
>   static int j = 3;
> 
>   iequals(__LINE__, i, j);
>   if (--i == 0)
> #if !defined(CPLUSPLUS) && !defined(C99)
>     return;
> #else
>     return 0;
> #endif
>   --j;
>   yfunc(i, pfn, pi);
>   iequals(__LINE__, i, j);
>   ++j;
>   pfn(pi);  /* converts to (*pfn)() */
> #if !defined(CPLUSPLUS) && !defined(C99)
>   /* no return expression, would be erroneous to use value */
> #else
>   return 0; /* must return expr, in C++ */
> #endif /* CPLUSPLUS */
> }
> 
>> I don't know the C90 standard well, but from the statement you quote it seems that Clang is non-conformant.
>> 
>> That said, from a user's perspective, Clang is doing the right thing: writing a "return" statement with no expression, in a function that has a non-void return type, is asking for trouble, and we're doing users a favor by rejecting it outright. Plum Hall isn't helping anyone by checking this.
> 
> As I read the test, the function is declared with no return type (i.e. implicit int).  This style was commonly used pre-C90 to declare functions that are logically void, as many compilers did not support void, and the C90 standard permits this usage in order to support such code.  How much of it is still around is an open question, probably not much, but I'm sure somebody stuck with maintaining such code would not consider it friendly to have the compiler reject it.

This is a good point;  it would be totally reasonable for us to consider this a hard error unless the return type is implicit.

John.