Re: GCC 3.0 Branch: Guidelines

[Joe Buck <jbuck at synopsys dot COM>]

>   The thing about returning a value from a void function should 
> probably still be allowed under -traditional, since it's just the flip
> side of the coin compared to not returning a value from a non-void
> function.

I go back far enough to have perused the V7 Unix sources (I briefly
used version 6 as well).  I know how C used to be written.

This is not true.

Originally, C didn't even have void, and it was common practice to
not declare void functions at all: the default type was int but values
would not be used.  For this reason, calling a plain "return;" in a
non-void function would mean that a lot of old code would not compile.
The standard way to write a void function, pre-void, was not to name
a return type at all, e.g.

foo() {
	do_something();
}

But if the user says "void", s/he has made a specific statement: this
function does not return a value.  There is no symmetry here.  Even
in K&R days, a user who explicitly declared a function void would not
purposely try to return a value from such a function!

> K&R C permitted this practice, and the return value of the
> function would generally correspond to whatever was calculated by the
> last expression evaluated before the function returned.  So before 
> completely killing the option it might be relevant to consider what
> would happen in an old K&R C program that had something like :
> 
> void foo (void)
> {
>    ...
>   return value;
> }

The above is nonsense.  No one wrote that kind of thing.  I challenge
you to find an actual program with such code in it.  You'll be very,
very unlikely to find one.  The reason is that (void) was not added
until prototypes were added.

> int bar (void)
> {
>    ...
>   foo ();
>   return;
> }

You probably won't find many functions like the above either.  What you
will find.  is

bar()
{
	foo();
	return;
}