From: | BartC <bc@freeuk.com> |
Newsgroups: | comp.compilers |
Date: | Tue, 6 Sep 2016 21:35:30 +0100 |
Organization: | A noiseless patient Spider |
References: | 16-09-001 16-09-005 16-09-009 |
Injection-Info: | miucha.iecc.com; posting-host="news.iecc.com:2001:470:1f07:1126:0:676f:7373:6970"; logging-data="87943"; mail-complaints-to="abuse@iecc.com" |
Keywords: | C, optimize, errors |
Posted-Date: | 08 Sep 2016 11:11:44 EDT |
On 06/09/2016 03:15, Kaz Kylheku wrote:
> On 2016-09-05, BartC <bc@freeuk.com> wrote:
>> I suspect [TCC] just compiles switch as an if-else chain. Which might
>> explain why duplicate case labels are ignored if that conversion is done
>> at at early stage.
>>
>> (Because a duplicate condition in an if-else chain is fine. For a
>> jump-table of course, a duplicate label is ambiguous so can't be allowed.)
>
> A duplicate condition in an if-else chain is unreachable code, which is
> probably a bug.
>
> if (foo) {
> ...
> } else if (foo) {
> /* unreachable */
> } else if (bar) {
> ...
> }
It's not necessarily unreachable. For example:
if (foo()) { ...}
elsif if (foo()) { ... }
foo() could return false the first time and true the second time.
In general detecting duplication conditions for if-else can involve
comparing expressions of arbitrary complexity, and it can be harder to
determine if they will always yield the same value.
(Unreachable code can also be made reachable by inserting a label with a
goto from elsewhere.)
> Duplicate cases are a constraint violation in ISO C, requiring a
> diagnostic.
> A duplicate label can also be just as "fine". Look, you can build a jump
> table, and then just fill it without caring about duplicates:
>
> case 42:
> ...
> case 42:
>
> No problem: just write to jumptable[42] twice, letting it the most
> recently established address overrule the previous one.
Some duplicate cases might be fine:
case 10: case 10:
as they both end up at the same place (and the 10s can be hidden behind
different macros or enums). But an error is still reported.
> Duplicate case label code can still be reachable, making the bugs
> potentially more interesting:
>
> case 42: // suppose this is used
> ...
> break;
> case 19:
> ...
> /* fallthrough */
> case 42: // this isn't used, but fallthrough makes it reachable
That's another way for duplicate cases to be meaningful, except that you
can't control which of the case 42s is put into the jump table. Unless
(in this case) you only use the first, so writing to jumptable[42] once
not twice.
But the sensible thing for switch is to report all duplicates (with a
possible concession when labels are at the same location, although that
could mask an error).
--
Bartc
Return to the
comp.compilers page.
Search the
comp.compilers archives again.