[...] switch(cptr[3]) { case 0xC0 ... 0xDF: [...]
I'm sorry to say, but this is not C. §6.6.4.2:1 of C99 (the current C standard says):
| The controlling expression of a switch statement shall have integer | type, and shall not cause a block to be entered by a jump from outside | the block to a statement that follows a case or default label in the | block (or an enclosed block) if that block contains the declaration of | a variably modified object or variably modified typedef name. The ^^^ | expression of each case label shall be an integer constant ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | expression. No two of the case constant expressions in the same switch ^^^^^^^^^^ | statement shall have the same value after conversion. There may be at | most one default label in a switch statement. (Any enclosed switch | statement may have a default label or case constant expressions with | values that duplicate case constant expressions in the enclosing | switch statement.)
"0xC0 ... 0xDF" is not an integer constant expression, so this is not legal C.
In the last episode (Nov 08), Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum said:
[...] switch(cptr[3]) { case 0xC0 ... 0xDF: [...]
I'm sorry to say, but this is not C. SS6.6.4.2:1 of C99 (the current C standard says):
Also beware of using // comments in C source (dvb.h:36 for example). It may be C99 standard, but many compilers are not.
It might be a good idea to use --std=c89 when compiling with gcc. That should warn for several constructions that are allowed by gcc and/or c99, but not by c89.
/ Niels Möller ()
Previous text:
2002-11-09 00:09: Subject: Re: psparser.c
In the last episode (Nov 08), Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum said:
[...] switch(cptr[3]) { case 0xC0 ... 0xDF: [...]
I'm sorry to say, but this is not C. SS6.6.4.2:1 of C99 (the current C standard says):
Also beware of using // comments in C source (dvb.h:36 for example). It may be C99 standard, but many compilers are not.
-- Dan Nelson dnelson@allantgroup.com
/ Brevbäraren
But that would make it warn about some things we _want_ to use and have proper tests for, wouldn't it? I'm thinking for example of the && on labels in --with-machine-code...
/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)
Previous text:
2002-11-10 11:04: Subject: Re: psparser.c
It might be a good idea to use --std=c89 when compiling with gcc. That should warn for several constructions that are allowed by gcc and/or c99, but not by c89.
/ Niels Möller ()
Then you'd need to disable that particular flag for one or two of the source files. So that makes it a little more complicated.
/ Niels Möller ()
Previous text:
2002-11-10 11:59: Subject: Re: psparser.c
But that would make it warn about some things we _want_ to use and have proper tests for, wouldn't it? I'm thinking for example of the && on labels in --with-machine-code...
/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)
And what about system header files? Can we know for sure that no header file provided by someone other than us will break with such a flag?
/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)
Previous text:
2002-11-10 12:04: Subject: Re: psparser.c
Then you'd need to disable that particular flag for one or two of the source files. So that makes it a little more complicated.
/ Niels Möller ()
I have never encountered any problems with headerfiles requiring gcc:ism or c99 features (and I think the opposite problem is more common: header files being older than ANSI-C). People tend to be conservative. So I think it could be worth it. But of course I can't say for sure that there won't be any problems.
/ Niels Möller ()
Previous text:
2002-11-10 12:11: Subject: Re: psparser.c
And what about system header files? Can we know for sure that no header file provided by someone other than us will break with such a flag?
/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)
pike-devel@lists.lysator.liu.se