Related articles |
---|
Alternative C compilers on x86_64 Linux? arnold@skeeve.com (2016-09-02) |
Re: Alternative C compilers on x86_64 Linux? bc@freeuk.com (BartC) (2016-09-05) |
Re: Alternative C compilers on x86_64 Linux? 221-501-9011@kylheku.com (Kaz Kylheku) (2016-09-06) |
Re: duplicate cases, was Alternative C compilers on x86_64 Linux? anw@cuboid.co.uk (Andy Walker) (2016-09-07) |
From: | Andy Walker <anw@cuboid.co.uk> |
Newsgroups: | comp.compilers |
Date: | Wed, 7 Sep 2016 17:01:56 +0100 |
Organization: | Not very much |
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="88293"; mail-complaints-to="abuse@iecc.com" |
Keywords: | C, optimize |
Posted-Date: | 08 Sep 2016 11:12:21 EDT |
On 06/09/16 03:15, Kaz Kylheku wrote:
> A duplicate condition in an if-else chain is unreachable code, which is
> probably a bug.
I note the "probably", but there are several ways this can happen
legitimately:
-- Language translation. Suppose we start with [in some other language]
something like
IF letter = 'q' THEN ...
ELIF letter IN ['a', 'e', 'i', 'o', 'u'] THEN ...
ELIF letter IN ['a' : 'z'] THEN ...
FI
and this gets turned automatically into either an "if-else" chain or a
bunch of cases in C, where 'q' and the vowels are tested twice.
-- Similar things can happen via macro expansion. What the coder sees
is often only loosely related to what later stages of compilation see!
-- Debugging. Eg, you don't want to deal with 'q' now, there are other
bugs you want to catch first. So you write
if (letter == 'q') { error (19); }
else if ...
in front of the code, and the "old" case 'q' is now unreachable.
Of course, deciding what constructs deserve warnings is a very
difficult problem in general, perhaps esp in languages like C where the
"coder" is often an automaton rather than a human.
--
Andy Walker,
Nottingham.
Return to the
comp.compilers page.
Search the
comp.compilers archives again.