Path: csiph.com!usenet.blueworldhosting.com!feeder01.blueworldhosting.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!news.iecc.com!.POSTED.news.iecc.com!nerds-end From: Andy Walker Newsgroups: comp.compilers Subject: Re: duplicate cases, was Alternative C compilers on x86_64 Linux? Date: Wed, 7 Sep 2016 17:01:56 +0100 Organization: Not very much Lines: 32 Sender: news@iecc.com Approved: comp.compilers@iecc.com Message-ID: <16-09-013@comp.compilers> References: <16-09-001@comp.compilers> <16-09-005@comp.compilers> <16-09-009@comp.compilers> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit 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 X-submission-address: compilers@iecc.com X-moderator-address: compilers-request@iecc.com X-FAQ-and-archives: http://compilers.iecc.com Xref: csiph.com comp.compilers:1752 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.