Re: [PATCH] More compile warning fixes for 2.4.0

Richard B. Johnson (root@chaos.analogic.com)
Tue, 9 Jan 2001 10:10:16 -0500 (EST)


On Tue, 9 Jan 2001, Albert D. Cahalan wrote:

> [about labels w/o statements after them]
>
> >> Is this really a kernel bug? This is common idiom in C, so gcc
> >> shouldn't warn about it. If it does, it is a bug in gcc IMHO.
> >
> > No, it is not a common idiom in C. It has _never_ been valid C.
> >
> > GCC originally allowed it due to a mistake in the grammar; we
> > now warn for it. Fix your source.
>
> Since neither -ansi nor -std=foo was specified, gcc should just
> shut up and be happy. Consider this as another GNU extension.
>

It has to do with ; "a label at the end of a compound statement..."
This has never been correctly allowed. Many don't realilize that
case 'X':
case 'Y':
default:

... are all labels. Modern compilers are now enforcing the rules.
When a 'switch' is a compound statement, tt follows the rules for
other compound statements. For instance, you can code (correctly)

switch(a) case 1: a--;

... this, with no braces at all. If a == 1, it gets changed to 0,
otherwise it is untouched. If we need another test, it becomes
a compound statement requiring braces as:

switch(a) { case 1: a--; default: }

Observe that we have tricked the compiler into generating code without
using a ';' denoting the end of a statement. The standards makers don't
like this and and now requiring that the above be coded as:

switch(a) { case 1: a--; default: ; }
^___ no tricks allowed.

A 'program unit', denoted by {} braces has never required a terminating
semicolon, so putting a ';' at the end of the physical statement
just won't do it in this case.

Cheers,
Dick Johnson

Penguin : Linux version 2.4.0 on an i686 machine (799.53 BogoMips).

"Memory is like gasoline. You use it up when you are running. Of
course you get it all back when you reboot..."; Actual explanation
obtained from the Micro$oft help desk.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/