Re: duplicate cases, was Alternative C compilers on x86_64 Linux?

Andy Walker <anw@cuboid.co.uk>
Wed, 7 Sep 2016 17:01:56 +0100

          From comp.compilers

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)
| List of all articles for this month |

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.


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.