Re: firebox build fails post clang-3.4 merge

On 02/27/14 12:24, David Chisnall wrote:
> On 27 Feb 2014, at 02:41, Michael Butler <imb_at_protected-networks.net> wrote:
> 
>> <sigh> .. way back in the late 70's or maybe early 80's when I was
>> actually doing some work on compilers, we had a saying: "produce correct
>> code even if it's not optimal or exit and tell the user why".

> In the late '70s, the number of transforms that a compiler could do
> were quite limited.  By the time the code gets to the back end in a
> modern compiler, it is often very difficult to map back to the source
> code and print a diagnostic more helpful than 'something in your
> program was undefined behaviour'.  This is why clang includes both
> static and dynamic checkers for undefined behaviour, in the form of
> the static analyser (you do run it on all code you right, don't you?)
> and the undefined behaviour sanitiser.

I guess what I'm trying to get at is that I am used to a compiler which
takes one of two actions, irrespective of the complexities of the source
language or target architecture ..

1) the compiler has no definitive translation of "semantic intent"
because the code is ambiguous - produces an error for the programmer to
that effect

2) the compiler has no idea how to translate unambiguous code into
functional machine code - produces an error for the compiler author(s)
benefit to expose missing code-generation cases

It seems that the current approach adopts a third action: embed
"land-mines" in the code without warning. I find this disturbing in the
extreme.

Can anyone say, without doubt, that there are none of these "land-mines"
in the kernel, libraries and utilities? If not, we just took a huge step
away from any kind of Information Assurance ..

	Michael