2.2.18 signal.h

2.2.18 signal.h

[Mike Black]

include/linux/signal.h

There's a couple like this -- isn't this case statement upside down???

extern inline void siginitset(sigset_t *set, unsigned long mask)
{
        set->sig[0] = mask;
        switch (_NSIG_WORDS) {
        default:
                memset(&set->sig[1], 0, sizeof(long)*(_NSIG_WORDS-1));
                break;
        case 2: set->sig[1] = 0;
        case 1:
        }
}

gcc is complaining:
/usr/src/linux/include/linux/signal.h:193: warning: deprecated use of label
at end of compound statement

________________________________________
Michael D. Black   Principal Engineer
mblack@csihq.com  321-676-2923,x203
http://www.csihq.com  Computer Science Innovations
http://www.csihq.com/~mike  My home page
FAX 321-676-2355

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

Re: 2.2.18 signal.h

[Andrea Arcangeli]

On Fri, Dec 15, 2000 at 11:29:28AM -0500, Mike Black wrote:
> include/linux/signal.h
> 
> There's a couple like this -- isn't this case statement upside down???
> 
> extern inline void siginitset(sigset_t *set, unsigned long mask)
> {
>         set->sig[0] = mask;
>         switch (_NSIG_WORDS) {
>         default:
>                 memset(&set->sig[1], 0, sizeof(long)*(_NSIG_WORDS-1));
>                 break;
>         case 2: set->sig[1] = 0;
>         case 1:
>         }
> }
> 
> gcc is complaining:
> /usr/src/linux/include/linux/signal.h:193: warning: deprecated use of label
> at end of compound statement

You're using a too recent gcc (I got flooded too indeed). I disagree with such
a warning, current code makes perfect sense.

Andrea
-
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/

Re: 2.2.18 signal.h

[Richard B. Johnson]

On Fri, 15 Dec 2000, Andrea Arcangeli wrote:

> On Fri, Dec 15, 2000 at 11:29:28AM -0500, Mike Black wrote:
> > include/linux/signal.h
> > 
> > There's a couple like this -- isn't this case statement upside down???
> > 
> > extern inline void siginitset(sigset_t *set, unsigned long mask)
> > {
> >         set->sig[0] = mask;
> >         switch (_NSIG_WORDS) {
> >         default:
> >                 memset(&set->sig[1], 0, sizeof(long)*(_NSIG_WORDS-1));
> >                 break;
> >         case 2: set->sig[1] = 0;
> >         case 1:
> >         }
> > }
> > 
> > gcc is complaining:
> > /usr/src/linux/include/linux/signal.h:193: warning: deprecated use of label
> > at end of compound statement
> 
> You're using a too recent gcc (I got flooded too indeed). I disagree with such
> a warning, current code makes perfect sense.
> 
> Andrea

Current code makes perfect sense if you put a 'break;' after the last
label. This doesn't generate any code, but makes the source comply with
the new rule.


Cheers,
Dick Johnson

Penguin : Linux version 2.4.0 on an i686 machine (799.54 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/

Re: 2.2.18 signal.h

[Andrea Arcangeli]

On Fri, Dec 15, 2000 at 12:07:55PM -0500, Richard B. Johnson wrote:
> Current code makes perfect sense if you put a 'break;' after the last

Current code makes perfect sense also without the break. I guess that's a
strict check to try to catch bugs, but calling it "deprecated" is wrong, it
should only say "warning: make sure that's not a bug" (when -Wall is enabled).

Andrea
-
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/

Re: 2.2.18 signal.h

[Franz Sirl]

At 18:43 15.12.00, Andrea Arcangeli wrote:
>On Fri, Dec 15, 2000 at 12:07:55PM -0500, Richard B. Johnson wrote:
> > Current code makes perfect sense if you put a 'break;' after the last
>
>Current code makes perfect sense also without the break. I guess that's a
>strict check to try to catch bugs, but calling it "deprecated" is wrong, it
>should only say "warning: make sure that's not a bug" (when -Wall is enabled).

It's required by ISO C, and since that's the standard now, gcc spits out a 
warning. Just adding a ; is enough and already done for most stuff in 
2.4.0-test12.

Franz.

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

Re: 2.2.18 signal.h

[Richard B. Johnson]

On Fri, 15 Dec 2000, Franz Sirl wrote:

> At 18:43 15.12.00, Andrea Arcangeli wrote:
> >On Fri, Dec 15, 2000 at 12:07:55PM -0500, Richard B. Johnson wrote:
> > > Current code makes perfect sense if you put a 'break;' after the last
> >
> >Current code makes perfect sense also without the break. I guess that's a
> >strict check to try to catch bugs, but calling it "deprecated" is wrong, it
> >should only say "warning: make sure that's not a bug" (when -Wall is enabled).
> 
> It's required by ISO C, and since that's the standard now, gcc spits out a 
> warning. Just adding a ; is enough and already done for most stuff in 
> 2.4.0-test12.
> 
> Franz.
> 

Right. I encountered something like this not too long ago in some
other gcc code that would not compile on a Sun.

	FYI, just because gcc lets you get away with some things (it
	knows what you want and tries to be helpful), that doesn't
	mean that the 'C' standard allows it.

	Here is a cute example:

	void foo()
        {
            extern int a;
            if(a) goto foo;
            return;
            foo:
	    printf("%d\n", a);
        }

	gcc allows you to use a label that has the same name as
	the function!
	It also allows you to use the name of a variable as a label!

	void foo()
	{
	   extern int a;
	   if(a) goto a;
	   return;
	   a:
	   printf("%d\n", a);
	}

	Both examples allow an extern declaration inside a function scope
	which is also contrary to any (even old) 'C' standards. 'extern'
	is always file scope, there's no way to make it otherwise.

Cheers,
Dick Johnson

Penguin : Linux version 2.4.0 on an i686 machine (799.54 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/

Re: 2.2.18 signal.h

[Alan Cox]

> 	void foo()
> 	{
> 	   extern int a;
> 	   if(a) goto a;
> 	   return;
> 	   a:
> 	   printf("%d\n", a);
> 	}
> 
> 	Both examples allow an extern declaration inside a function scope
> 	which is also contrary to any (even old) 'C' standards. 'extern'
> 	is always file scope, there's no way to make it otherwise.

extern in function scope is in original C. In fact its even _older_ than that
its in the B compiler too - although in B its 'extrn' not 'extern'.

Alan (yes I programmed in B)

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

Re: 2.2.18 signal.h

[Horst von Brand]

"Richard B. Johnson" <root@chaos.analogic.com> said:

[...]

> 	Both examples allow an extern declaration inside a function scope
> 	which is also contrary to any (even old) 'C' standards. 'extern'
> 	is always file scope, there's no way to make it otherwise.

AFAIR (rather dimly... no K&R at hand here) if you have an extern
declaration inside a block, it will be visible only within that block. The
object itself certainly is file scope (or larger).
-- 
Dr. Horst H. von Brand                       mailto:vonbrand@inf.utfsm.cl
Departamento de Informatica                     Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria              +56 32 654239
Casilla 110-V, Valparaiso, Chile                Fax:  +56 32 797513
-
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/

Re: 2.2.18 signal.h

[Michael Meissner]

On Fri, Dec 15, 2000 at 04:06:36PM -0300, Horst von Brand wrote:
> "Richard B. Johnson" <root@chaos.analogic.com> said:
> 
> [...]
> 
> > 	Both examples allow an extern declaration inside a function scope
> > 	which is also contrary to any (even old) 'C' standards. 'extern'
> > 	is always file scope, there's no way to make it otherwise.
> 
> AFAIR (rather dimly... no K&R at hand here) if you have an extern
> declaration inside a block, it will be visible only within that block. The
> object itself certainly is file scope (or larger).

Old K&R allowed the following:

	foo(){
	  extern int a;

	  a = 1;
	}

	bar(){
	  a = 2;
	}

Ie, compiler put the definition for a in the file scope symbol table, and not
the current block's.  The above example is illegal in ISO C.

-- 
Michael Meissner, Red Hat, Inc.  (GCC group)
PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA
Work:	  meissner@redhat.com		phone: +1 978-486-9304
Non-work: meissner@spectacle-pond.org	fax:   +1 978-692-4482
-
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/

Re: 2.2.18 signal.h

[Andrea Arcangeli]

On Fri, Dec 15, 2000 at 06:59:24PM +0100, Franz Sirl wrote:
> It's required by ISO C, and since that's the standard now, gcc spits out a 
> warning. Just adding a ; is enough and already done for most stuff in 
> 2.4.0-test12.

I'm not complaining gcc folks, I just dislike the new behaviour in general,
it's inconsistent.

This is wrong:

x()
{

	switch (1) {
	case 0:
	case 1:
	case 2:
	case 3:
	}
}

and this is right:

x()
{

	switch (1) {
	case 0:
	case 1:
	case 2:
	case 3:
	;
	}
}

Why am I required to put a `;' only in the last case and not in all
the previous ones? Or maybe gcc-latest is forgetting to complain about
the previous ones ;)

Anyway it's a minor issue, if the standard says so we'll live with it.

(and it's also getting offtopic...)

Andrea
-
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/

Re: 2.2.18 signal.h

[Ulrich Drepper]

Andrea Arcangeli <andrea@suse.de> writes:

> x()
> {
> 
> 	switch (1) {
> 	case 0:
> 	case 1:
> 	case 2:
> 	case 3:
> 	;
> 	}
> }
> 
> Why am I required to put a `;' only in the last case and not in all
> the previous ones? Or maybe gcc-latest is forgetting to complain about
> the previous ones ;)

Your C language knowledge seems to have holes.  It must be possible to
have more than one label for a statement.  Look through the kernel
sources, there are definitely cases where this is needed.

-- 
---------------.                          ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Red Hat          `--' drepper at redhat.com   `------------------------
-
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/

Re: 2.2.18 signal.h

[Andrea Arcangeli]

On Fri, Dec 15, 2000 at 11:18:35AM -0800, Ulrich Drepper wrote:
> Andrea Arcangeli <andrea@suse.de> writes:
> 
> > x()
> > {
> > 
> > 	switch (1) {
> > 	case 0:
> > 	case 1:
> > 	case 2:
> > 	case 3:
> > 	;
> > 	}
> > }
> > 
> > Why am I required to put a `;' only in the last case and not in all
> > the previous ones? Or maybe gcc-latest is forgetting to complain about
> > the previous ones ;)
> 
> Your C language knowledge seems to have holes.  It must be possible to
> have more than one label for a statement.  Look through the kernel
> sources, there are definitely cases where this is needed.

I don't understand what you're talking about. Who ever talked about "more than
one label"?

The only issue here is having 1 random label at the end of a compound
statement. Nothing else.

And yes I can see that the whole point of the change is that they want
to also forbids this:

x()
{
	goto out;
out:
}

and I dislike not being allowed to do the above as well infact ;).

Andrea
-
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/

Re: 2.2.18 signal.h

[Rik van Riel]

On Fri, 15 Dec 2000, Andrea Arcangeli wrote:

> And yes I can see that the whole point of the change is that
> they want to also forbids this:
> 
> x()
> {
> 	goto out;
> out:
> }
> 
> and I dislike not being allowed to do the above as well infact ;).

What's wrong with the - more readable - `break;' ?

regards,

Rik
--
Hollywood goes for world dumbination,
	Trailer at 11.

		http://www.surriel.com/
http://www.conectiva.com/	http://distro.conectiva.com.br/

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

Re: 2.2.18 signal.h

[Andrea Arcangeli]

On Fri, Dec 15, 2000 at 06:09:16PM -0200, Rik van Riel wrote:
> On Fri, 15 Dec 2000, Andrea Arcangeli wrote:
> 
> > And yes I can see that the whole point of the change is that
> > they want to also forbids this:
> > 
> > x()
> > {
> > 	goto out;
> > out:
> > }
> > 
> > and I dislike not being allowed to do the above as well infact ;).
> 
> What's wrong with the - more readable - `break;' ?

You meant "return" of course as you can't put a break there (there's no loop).

`return' doesn't define the fast path (but ok it's a minor issue and
I think latest gcc can use some stuff to define fast paths).

In general all I'm saying is that they don't want a label before the end of a
compound statement and that's a not interesting requirement IMHO that will just
force people to use one additional "suprious" `;' after the last label. It
doesn't make the code more readable and it doesn't give any advantage other
than maybe having simplified some formal language definition.

Andrea
-
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/

Re: 2.2.18 signal.h

[Anuradha Ratnaweera]

On Fri, 15 Dec 2000, Andrea Arcangeli wrote:

> On Fri, Dec 15, 2000 at 11:18:35AM -0800, Ulrich Drepper wrote:
> > Andrea Arcangeli <andrea@suse.de> writes:
> > 
> > > x()
> > > {
> > > 
> > > 	switch (1) {
> > > 	case 0:
> > > 	case 1:
> > > 	case 2:
> > > 	case 3:
> > > 	;
> > > 	}
> > > }
> > > 
> > > Why am I required to put a `;' only in the last case and not in all
> > > the previous ones? Or maybe gcc-latest is forgetting to complain about
> > > the previous ones ;)
> > 
> > Your C language knowledge seems to have holes.  It must be possible to
> > have more than one label for a statement.  Look through the kernel
> > sources, there are definitely cases where this is needed.
> 
> I don't understand what you're talking about. Who ever talked about
> "more than one label"?

In simple terms all four `case'es form a single entity and therefore a
statement is necessary AFTER them and not in the MIDDLE. That is why gcc
doesn't complain about the `previous' ones.
 
> The only issue here is having 1 random label at the end of a compound
> statement. Nothing else.

That is NOT the issue. It has nothing to do with the compound statement.
There should be a statement after ONE OR MORE "case"s, but here

case 0: case 1: case 2: case 3:

is NOT followed by a statement.

> And yes I can see that the whole point of the change is that they want
> to also forbids this:
> 
> x()
> {
> 	goto out;
> out:
> }

Again this is a similar case. But if you write

x()
{
  goto out1;
  goto out2;

out1:
out2:
}

GCC will complain the absence of a statement after `out1:out2:`, but not
two complains for `out1' and `out2', because they form a single entity.


Anuradha




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

Re: 2.2.18 signal.h

[Andrea Arcangeli]

On Sat, Dec 16, 2000 at 01:53:50PM +0600, Anuradha Ratnaweera wrote:
> GCC will complain the absence of a statement after `out1:out2:`, but not
> two complains for `out1' and `out2', because they form a single entity.

I understand the formal specs (the email from Michael is very clear). What I'm
saying is that as the `dummy' statement is redoundant information but you're
requiring us to put it to build a labeled-statement, you could been even more
lazy and not define the labeled-statement as a statement so requiring us to put
a dummy statement after every label. That would been the same kind of issue
we're facing right now (but of course defining a labeled-statement as a
statement and allowing recursion makes the formal specs even simpler so that
probably wouldn't happen that easily).

Andrea
-
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/

Re: 2.2.18 signal.h

[Michael Meissner]

On Sat, Dec 16, 2000 at 02:52:42PM +0100, Andrea Arcangeli wrote:
> On Sat, Dec 16, 2000 at 01:53:50PM +0600, Anuradha Ratnaweera wrote:
> > GCC will complain the absence of a statement after `out1:out2:`, but not
> > two complains for `out1' and `out2', because they form a single entity.
> 
> I understand the formal specs (the email from Michael is very clear). What I'm
> saying is that as the `dummy' statement is redoundant information but you're
> requiring us to put it to build a labeled-statement, you could been even more
> lazy and not define the labeled-statement as a statement so requiring us to put
> a dummy statement after every label. That would been the same kind of issue
> we're facing right now (but of course defining a labeled-statement as a
> statement and allowing recursion makes the formal specs even simpler so that
> probably wouldn't happen that easily).

Basically, that's the way Dennis Ritchie decided it should be 26-27 years ago
(C emerged between 1972 and 1973, according to the published history).  It may
be that C's ancestor languages (B and BCPL) had the same syntax, but since I've
never used them, I can't say.  Ultimately, all syntax is arbitrary, merely an
agreement between language designers, implementers, standards committees and
users.  FWIW, it is rather low on my radar screen.  If I had a magic Delorean
and could go back in time to make some changes, I would:

   1)	Make all stdio functions consistant in taking the FILE * argument as
	the first argument.

   2)	Make && and || have the proper priority.

   3)	Make plain char and bitfields unsigned by default, add signed keyword
	to the original language.

   4)	Allow optional trailing ',' in enumeration lists.

-- 
Michael Meissner, Red Hat, Inc.  (GCC group)
PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA
Work:	  meissner@redhat.com		phone: +1 978-486-9304
Non-work: meissner@spectacle-pond.org	fax:   +1 978-692-4482
-
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/

Re: 2.2.18 signal.h

[Rik van Riel]

On Fri, 15 Dec 2000, Andrea Arcangeli wrote:

> x()
> {
> 
> 	switch (1) {
> 	case 0:
> 	case 1:
> 	case 2:
> 	case 3:
> 	;
> 	}
> }
> 
> Why am I required to put a `;' only in the last case and not in
> all the previous ones?

That `;' above is NOT in just the last one. In your above
example, all the labels will execute the same `;' statement.

In fact, the default behaviour of the switch() operation is
to fall through to the next defined label and you have to put
in an explicit `break;' if you want to prevent `case 0:' from
reaching the `;' below the `case 3:'...

regards,

Rik
--
Hollywood goes for world dumbination,
	Trailer at 11.

		http://www.surriel.com/
http://www.conectiva.com/	http://distro.conectiva.com.br/

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

Re: 2.2.18 signal.h

[Andrea Arcangeli]

On Fri, Dec 15, 2000 at 05:55:08PM -0200, Rik van Riel wrote:
> On Fri, 15 Dec 2000, Andrea Arcangeli wrote:
> 
> > x()
> > {
> > 
> > 	switch (1) {
> > 	case 0:
> > 	case 1:
> > 	case 2:
> > 	case 3:
> > 	;
> > 	}
> > }
> > 
> > Why am I required to put a `;' only in the last case and not in
> > all the previous ones?
> 
> That `;' above is NOT in just the last one. In your above
> example, all the labels will execute the same `;' statement.
> 
> In fact, the default behaviour of the switch() operation is
> to fall through to the next defined label and you have to put
> in an explicit `break;' if you want to prevent `case 0:' from
> reaching the `;' below the `case 3:'...

Are you kidding me?

Andrea
-
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/

Re: 2.2.18 signal.h

[Thomas Dodd]

Andrea Arcangeli wrote:
> 
> On Fri, Dec 15, 2000 at 05:55:08PM -0200, Rik van Riel wrote:
> > On Fri, 15 Dec 2000, Andrea Arcangeli wrote:
> >
> > > x()
> > > {
> > >
> > >     switch (1) {
> > >     case 0:
> > >     case 1:
> > >     case 2:
> > >     case 3:
> > >     ;
> > >     }
> > > }
> > >
> > > Why am I required to put a `;' only in the last case and not in
> > > all the previous ones?
> >
> > That `;' above is NOT in just the last one. In your above
> > example, all the labels will execute the same `;' statement.
> >
> > In fact, the default behaviour of the switch() operation is
> > to fall through to the next defined label and you have to put
> > in an explicit `break;' if you want to prevent `case 0:' from
> > reaching the `;' below the `case 3:'...
> 
> Are you kidding me?

Absolutely NOT.

switch (x) {
  case 0:
  case 1:
      printf ("%d\n", x);
      break;
  case 2:
      printf ("%d\n",x*x);
  case 3:
      printf ("%d\n", x*x*x);
 }

if x==0 or 1, prints x (the 0 or one),
if x==2 , it prints 4 and 8  since no break statement exits the switch,
if x==3, it prints only 27,
any othe value of x, and nothing is printed.

Every C compile I have ever used does this.
Sun's C and C++, HP's C, Microsoft's VC++, Borland's C, and all versions
of gcc and g++.

Grab any C programming book, and find the switch statement.

	-Thomas
-
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/

Re: 2.2.18 signal.h

[Andrea Arcangeli]

On Thu, Dec 21, 2000 at 12:18:56PM -0600, Thomas Dodd wrote:
> Andrea Arcangeli wrote:
> > 
> > On Fri, Dec 15, 2000 at 05:55:08PM -0200, Rik van Riel wrote:
> > > On Fri, 15 Dec 2000, Andrea Arcangeli wrote:
> > >
> > > > x()
> > > > {
> > > >
> > > >     switch (1) {
> > > >     case 0:
> > > >     case 1:
> > > >     case 2:
> > > >     case 3:
> > > >     ;
> > > >     }
> > > > }
> > > >
> > > > Why am I required to put a `;' only in the last case and not in
> > > > all the previous ones?
> > >
> > > That `;' above is NOT in just the last one. In your above
> > > example, all the labels will execute the same `;' statement.
> > >
> > > In fact, the default behaviour of the switch() operation is
      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > > to fall through to the next defined label and you have to put
      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > > in an explicit `break;' if you want to prevent `case 0:' from
      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > > reaching the `;' below the `case 3:'...
      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > 
> > Are you kidding me?
> 
> Absolutely NOT.
> 
> switch (x) {
>   case 0:
>   case 1:
>       printf ("%d\n", x);
>       break;
>   case 2:
>       printf ("%d\n",x*x);
>   case 3:
>       printf ("%d\n", x*x*x);
>  }
> 
> if x==0 or 1, prints x (the 0 or one),
> if x==2 , it prints 4 and 8  since no break statement exits the switch,
> if x==3, it prints only 27,
> any othe value of x, and nothing is printed.
> 
> Every C compile I have ever used does this.
> Sun's C and C++, HP's C, Microsoft's VC++, Borland's C, and all versions
> of gcc and g++.
> 
> Grab any C programming book, and find the switch statement.

What I need is an English book, not a C book ;). Chip told me I should have
written "Do you really think I don't know that?" while referring to the
underlined text. If it wasn't obvious I hope it's clear now. Thanks to Chip for
the English lesson.

Andrea
-
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/

Re: 2.2.18 signal.h

[Michael Meissner]

On Fri, Dec 15, 2000 at 07:54:33PM +0100, Andrea Arcangeli wrote:
> On Fri, Dec 15, 2000 at 06:59:24PM +0100, Franz Sirl wrote:
> > It's required by ISO C, and since that's the standard now, gcc spits out a 
> > warning. Just adding a ; is enough and already done for most stuff in 
> > 2.4.0-test12.
> 
> I'm not complaining gcc folks, I just dislike the new behaviour in general,
> it's inconsistent.
> 
> This is wrong:
> 
> x()
> {
> 
> 	switch (1) {
> 	case 0:
> 	case 1:
> 	case 2:
> 	case 3:
> 	}
> }
> 
> and this is right:
> 
> x()
> {
> 
> 	switch (1) {
> 	case 0:
> 	case 1:
> 	case 2:
> 	case 3:
> 	;
> 	}
> }
> 
> Why am I required to put a `;' only in the last case and not in all
> the previous ones? Or maybe gcc-latest is forgetting to complain about
> the previous ones ;)

Because neither

	<label>:		(nor)
	case <expr>:		(nor)
	default:

are statements by themselves.  They are an optional start of a statement.  The
ebnf looks like:

	statement:
		  labeled-statement
		| expression-statem
		| compoundstatement
		| selection-statement
		| iteration-statement
		| jump-statement

	labeled-statement:
		  identifier ':' statement
		| 'case' constant-expression ':' statement
		| 'default' ':' statement

-- 
Michael Meissner, Red Hat, Inc.  (GCC group)
PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA
Work:	  meissner@redhat.com		phone: +1 978-486-9304
Non-work: meissner@spectacle-pond.org	fax:   +1 978-692-4482
-
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/

Re: 2.2.18 signal.h

[Albert D. Cahalan]

Michael Meissner writes:
> On Fri, Dec 15, 2000 at 07:54:33PM +0100, Andrea Arcangeli wrote:
>> On Fri, Dec 15, 2000 at 06:59:24PM +0100, Franz Sirl wrote:

>>> It's required by ISO C, and since that's the standard now, gcc
>>> spits out a  warning. Just adding a ; is enough and already
>>> done for most stuff in 2.4.0-test12.
...
>> Why am I required to put a `;' only in the last case and not in
>> all the previous ones? Or maybe gcc-latest is forgetting to
>> complain about the previous ones ;)
>
> Because neither
> 
> 	<label>:		(nor)
> 	case <expr>:		(nor)
> 	default:
> 
> are statements by themselves.

For the GNU C language they are. For the ISO C language they are not.
If there had been a flag such as -ansi or -std=iso-me-harder then
the warning would be appropriate. Without such a flag, gcc should
shut up and compile the code.

So this is a gcc language standard selection bug.


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

Re: 2.2.18 signal.h

[Jesse Pollard]

---------  Received message begins Here  ---------

> From: Andrea Arcangeli <andrea@suse.de>
> On Fri, Dec 15, 2000 at 11:18:35AM -0800, Ulrich Drepper wrote:
> > Andrea Arcangeli <andrea@suse.de> writes:
> > 
> > > x()
> > > {
> > > 
> > > 	switch (1) {
> > > 	case 0:
> > > 	case 1:
> > > 	case 2:
> > > 	case 3:
> > > 	;
> > > 	}
> > > }
> > > 
> > > Why am I required to put a `;' only in the last case and not in all
> > > the previous ones? Or maybe gcc-latest is forgetting to complain about
> > > the previous ones ;)
> > 
> > Your C language knowledge seems to have holes.  It must be possible to
> > have more than one label for a statement.  Look through the kernel
> > sources, there are definitely cases where this is needed.
> 
> I don't understand what you're talking about. Who ever talked about "more than
> one label"?
> 
> The only issue here is having 1 random label at the end of a compound
> statement. Nothing else.

The label must be on an expression. Until the ";" is present to indicate
a null expression it is syntacticly incorrect to have

switch (x) {
1:
2: something;
3:
}

The "3:" needs an expression to satisfy the syntax of "switch".

> And yes I can see that the whole point of the change is that they want
> to also forbids this:
> 
> x()
> {
> 	goto out;
> out:
> }
> 
> and I dislike not being allowed to do the above as well infact ;).

I think this has the same requirement. A null expression, specified with
the ";" is a small price to pay for simplifying the error detection.

-------------------------------------------------------------------------
Jesse I Pollard, II
Email: pollard@navo.hpc.mil

Any opinions expressed are solely my own.
-
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/

Re: 2.2.18 signal.h

[Andrea Arcangeli]

On Fri, Dec 15, 2000 at 03:56:52PM -0600, Jesse Pollard wrote:
> [..] A null expression, specified with
> the ";" is a small price to pay for simplifying the error detection. [..]

I'm not convinced this is a significant simplification (also considering the
"hard" way is just working fine). I think it's only to be compliant with the
standard and despite me not liking having to duplicate even more information in
the sources, that's a good thing.

Andrea
-
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/