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/
Quoted 16 lines · Mike Black
include/linux/signal.hThere'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: } }
Quoted 3 lines
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/
Quoted 17 lines · Andrea Arcangeli
Quoted 16 lines · Mike Black
include/linux/signal.hThere'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: } }
Quoted 8 lines
Quoted 3 lines
gcc is complaining:
/usr/src/linux/include/linux/signal.h:193: warning: deprecated use of label at end of compound statementYou'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/
Quoted 3 lines · Franz Sirl
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/
Quoted 12 lines · Andrea Arcangeli
x()
{switch (1) { case 0: case 1: case 2: case 3: ; } }
Quoted 2 lines
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/
Quoted 17 lines · Rik van Riel
Quoted 12 lines · Andrea Arcangeli
x()
{switch (1) { case 0: case 1: case 2: case 3: ; } }Quoted 2 lines
Why am I required to put a `;' only in the last case and not in all the previous ones?
Quoted 7 lines
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 explicitbreak;' if you want to preventcase 0:' from reaching the;' below thecase 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/
Quoted 22 lines · Andrea Arcangeli
Quoted 20 lines · Rik van Riel
Quoted 12 lines · Andrea Arcangeli
x()
{switch (1) { case 0: case 1: case 2: case 3: ; } }Quoted 2 lines
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.
Quoted 6 lines
Quoted 4 lines
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 explicitbreak;' if you want to preventcase 0:' from reaching the;' below thecase 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/
Quoted 17 lines · Thomas Dodd
Quoted 16 lines · Andrea Arcangeli
Quoted 14 lines · Rik van Riel
Quoted 12 lines · Andrea Arcangeli
x()
{switch (1) { case 0: case 1: case 2: case 3: ; } }
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 2 lines
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
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Quoted 1 line
Quoted 1 line
Quoted 1 line
to fall through to the next defined label and you have to put
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Quoted 1 line
Quoted 1 line
Quoted 1 line
in an explicit
break;' if you want to preventcase 0:' from
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Quoted 1 line
Quoted 1 line
Quoted 1 line
reaching the
;' below thecase 3:'...
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Quoted 21 lines
Quoted 2 lines
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.
Quoted 5 lines
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/
Quoted 12 lines · Andrea Arcangeli
x()
{switch (1) { case 0: case 1: case 2: case 3: ; } }
Quoted 3 lines
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.
Signature · 7 lines
---------------. ,-. 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/
Quoted 14 lines · Ulrich Drepper
Quoted 12 lines · Andrea Arcangeli
x()
{switch (1) { case 0: case 1: case 2: case 3: ; } }
Quoted 7 lines
Quoted 3 lines
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/
Quoted 10 lines · Andrea Arcangeli
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/
Quoted 11 lines · Rik van Riel
Quoted 9 lines · Andrea Arcangeli
And yes I can see that the whole point of the change is that they want to also forbids this:
x(){ goto out;out:
}
Quoted 3 lines
Quoted 1 line
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/
Quoted 19 lines · Andrea Arcangeli
Quoted 18 lines · Ulrich Drepper
Quoted 15 lines · Andrea Arcangeli
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 ;)
Quoted 6 lines
Quoted 3 lines
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.
Quoted 2 lines
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.
Quoted 8 lines
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/
Quoted 2 lines · Anuradha Ratnaweera
GCC will complain the absence of a statement after
out1:out2:, but not two complains forout1' andout2', 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/
Quoted 4 lines · Andrea Arcangeli
Quoted 2 lines · Anuradha Ratnaweera
GCC will complain the absence of a statement after
out1:out2:, but not two complains forout1' andout2', because they form a single entity.
Quoted 8 lines
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.
Signature · 8 lines
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/
Quoted 35 lines · Andrea Arcangeli
Quoted 3 lines · Franz Sirl
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: ; } }
Quoted 3 lines
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
Signature · 8 lines
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/
Quoted 6 lines · Michael Meissner
Quoted 5 lines · Andrea Arcangeli
Quoted 3 lines · Franz Sirl
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.
...
Quoted 11 lines
Quoted 3 lines
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/
Quoted 1 line · Richard B. Johnson
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/
Quoted 6 lines · Andrea Arcangeli
Quoted 1 line · Richard B. Johnson
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/
Quoted 8 lines · Franz Sirl
Quoted 6 lines · Andrea Arcangeli
Quoted 1 line · Richard B. Johnson
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).
Quoted 6 lines
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/
Quoted 4 lines
void foo()
{
extern int a;
if(a) goto a;Quoted 8 lines
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/
"Richard B. Johnson" <[email protected]> said:
[...]
Quoted 3 lines
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).
Signature · 8 lines
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, Chile Fax: +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/
Quoted 11 lines · Horst von Brand
"Richard B. Johnson" <[email protected]> said:
[...]
Quoted 3 lines
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.
Signature · 8 lines
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/