|Alternative C compilers on x86_64 Linux? firstname.lastname@example.org (2016-09-02)|
|Re: Alternative C compilers on x86_64 Linux? email@example.com (jacobnavia) (2016-09-05)|
|Re: Alternative C compilers on x86_64 Linux? firstname.lastname@example.org (2016-09-05)|
|Re: diagnosing C errors, was Alternative C compilers on x86_64 Linux? email@example.com (BartC) (2016-09-09)|
|Re: diagnosing C errors, was Alternative C compilers on x86_64 Linux? firstname.lastname@example.org (Kaz Kylheku) (2016-09-09)|
|Re: diagnosing C errors, was Alternative C compilers on x86_64 Linux? DrDiettrich1@netscape.net (Hans-Peter Diettrich) (2016-09-10)|
|From:||Kaz Kylheku <email@example.com>|
|Date:||Fri, 9 Sep 2016 16:06:54 +0000 (UTC)|
|Organization:||Aioe.org NNTP Server|
|References:||16-09-001 16-09-002 16-09-008 16-09-019|
|Injection-Info:||miucha.iecc.com; posting-host="news.iecc.com:2001:470:1f07:1126:0:676f:7373:6970"; logging-data="71168"; mail-complaints-to="firstname.lastname@example.org"|
|Posted-Date:||09 Sep 2016 14:51:04 EDT|
On 2016-09-09, BartC <email@example.com> wrote:
> On 06/09/2016 01:26, firstname.lastname@example.org 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
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
Return to the
Search the comp.compilers archives again.