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: Kaz Kylheku <221-501-9011@kylheku.com> Newsgroups: comp.compilers Subject: Re: diagnosing C errors, was Alternative C compilers on x86_64 Linux? Date: Fri, 9 Sep 2016 16:06:54 +0000 (UTC) Organization: Aioe.org NNTP Server Lines: 43 Sender: news@iecc.com Approved: comp.compilers@iecc.com Message-ID: <16-09-020@comp.compilers> References: <16-09-001@comp.compilers> <16-09-002@comp.compilers> <16-09-008@comp.compilers> <16-09-019@comp.compilers> Injection-Info: miucha.iecc.com; posting-host="news.iecc.com:2001:470:1f07:1126:0:676f:7373:6970"; logging-data="71168"; mail-complaints-to="abuse@iecc.com" Keywords: C, errors Posted-Date: 09 Sep 2016 14:51:04 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:1759 On 2016-09-09, BartC wrote: > On 06/09/2016 01:26, alexfrunews@gmail.com wrote: >> On Sunday, September 4, 2016 at 3:56:56 PM UTC-7, jacobnavia wrote: >>> Why should they care? If you write duplicate switch cases its not their >>> fault, its yours. >> >> It is a constraint violation, and a trivial one, that the compiler >> must identify and report instead of silently producing code that is >> broken or appears to work by chance. > > This is C. There are already plenty of things that it lets through that > are probably errors, and which are likely to crash the program. That's true. The major real-world consequence of not producing an ISO-C required diagnostic is that the code will fail to compile on compilers other than the one with which it was developed. Though you may have some dead code in a switch statement, and that could be a bug, on the other hand, you test the code. It's not a bug if there is no external test case which reproduces an issue. And that brings us to Aharon's original point about looking for a compiler that can be used for *development*. A compiler used for development should have excellent diagnostics, which helps make the code cleanly portable to other compilers. > By contrast, an inadvertent duplicate case label is a 'soft' error; the > program just won't give the expected results. Or, as I argue about, there might in fact be no bug: the correct fix might in fact be just to remove the duplicate label and all the code under it. Some ISO C required diagnostics do help uncover real errors, which helps, in spite of the C language having lots of pitfalls and holes. Imagine if you could assign any scalar type to any other without needing a cast, and with no diagnostic: double x = "abc", and so on. Or call functions without any parameter checking. The type checking in C does a lot for improving the reliability of C programs, even though it falls far short of repairing all the holes and pitfalls.