Re: 2.2.18 signal.h
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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.2.18 signal.h
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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.2.18 signal.h
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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.2.18 signal.h
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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.2.18 signal.h
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: [EMAIL PROTECTED] phone: +1 978-486-9304 Non-work: [EMAIL PROTECTED] fax: +1 978-692-4482 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.2.18 signal.h
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: [EMAIL PROTECTED] phone: +1 978-486-9304 Non-work: [EMAIL PROTECTED] fax: +1 978-692-4482 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.2.18 signal.h
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 > > :(nor) > case :(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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.2.18 signal.h
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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.2.18 signal.h
On Fri, 15 Dec 2000, Andrea Arcangeli wrote: > On Fri, Dec 15, 2000 at 11:18:35AM -0800, Ulrich Drepper wrote: > > Andrea Arcangeli <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.2.18 signal.h
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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.2.18 signal.h
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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.2.18 signal.h
On Fri, 15 Dec 2000, Andrea Arcangeli wrote: On Fri, Dec 15, 2000 at 11:18:35AM -0800, Ulrich Drepper wrote: Andrea Arcangeli [EMAIL PROTECTED] 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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.2.18 signal.h
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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.2.18 signal.h
- Received message begins Here - > From: Andrea Arcangeli <[EMAIL PROTECTED]> > On Fri, Dec 15, 2000 at 11:18:35AM -0800, Ulrich Drepper wrote: > > Andrea Arcangeli <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] 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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.2.18 signal.h
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 :(nor) case :(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: [EMAIL PROTECTED] phone: +1 978-486-9304 Non-work: [EMAIL PROTECTED] fax: +1 978-692-4482 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.2.18 signal.h
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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.2.18 signal.h
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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.2.18 signal.h
On Fri, Dec 15, 2000 at 04:06:36PM -0300, Horst von Brand wrote: > "Richard B. Johnson" <[EMAIL PROTECTED]> 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 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 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: [EMAIL PROTECTED] phone: +1 978-486-9304 Non-work: [EMAIL PROTECTED] fax: +1 978-692-4482 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.2.18 signal.h
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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.2.18 signal.h
On Fri, Dec 15, 2000 at 11:18:35AM -0800, Ulrich Drepper wrote: > Andrea Arcangeli <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.2.18 signal.h
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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.2.18 signal.h
Andrea Arcangeli <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.2.18 signal.h
"Richard B. Johnson" <[EMAIL PROTECTED]> 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 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:[EMAIL PROTECTED] Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, ChileFax: +56 32 797513 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.2.18 signal.h
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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.2.18 signal.h
> 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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.2.18 signal.h
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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.2.18 signal.h
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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.2.18 signal.h
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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.2.18 signal.h
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(>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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.2.18 signal.h
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(>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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
2.2.18 signal.h
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(>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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
2.2.18 signal.h
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.2.18 signal.h
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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.2.18 signal.h
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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.2.18 signal.h
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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.2.18 signal.h
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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.2.18 signal.h
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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.2.18 signal.h
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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.2.18 signal.h
"Richard B. Johnson" [EMAIL PROTECTED] 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 KR 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:[EMAIL PROTECTED] Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, ChileFax: +56 32 797513 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.2.18 signal.h
Andrea Arcangeli [EMAIL PROTECTED] 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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.2.18 signal.h
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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.2.18 signal.h
On Fri, Dec 15, 2000 at 11:18:35AM -0800, Ulrich Drepper wrote: Andrea Arcangeli [EMAIL PROTECTED] 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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.2.18 signal.h
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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.2.18 signal.h
On Fri, Dec 15, 2000 at 04:06:36PM -0300, Horst von Brand wrote: "Richard B. Johnson" [EMAIL PROTECTED] 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 KR 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 KR 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: [EMAIL PROTECTED] phone: +1 978-486-9304 Non-work: [EMAIL PROTECTED] fax: +1 978-692-4482 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.2.18 signal.h
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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.2.18 signal.h
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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.2.18 signal.h
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: [EMAIL PROTECTED] phone: +1 978-486-9304 Non-work: [EMAIL PROTECTED] fax: +1 978-692-4482 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.2.18 signal.h
- Received message begins Here - From: Andrea Arcangeli [EMAIL PROTECTED] On Fri, Dec 15, 2000 at 11:18:35AM -0800, Ulrich Drepper wrote: Andrea Arcangeli [EMAIL PROTECTED] 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: [EMAIL PROTECTED] 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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.2.18 signal.h
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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/