[LLVMdev] C as used/implemented in practice: analysis of responses

[Peter Sewell]

On 1 July 2015 at 10:17, Renato Golin <renato.golin at linaro.org> wrote:
> On 1 July 2015 at 03:53, Sean Silva <chisophugis at gmail.com> wrote:
>> Unfortunately in other cases it is very hard to communicate what the user
>> should assert/why they should assert it, as Chris talks about in his blog
>> posts. So it realistically becomes sort of black and white -- either don't
>> optimize based on UB or do. For what is probably just social reasons, the
>> desire to optimize wins out; from an economic standpoint (e.g. power saved)
>> it overall may be the right choice (I haven't run any ballpark figures
>> though and don't claim this to be true).
>
> This is *so* true. There's a natural progression of programmers as
> they age. Initially, people are adverse of side effects and they hate
> "misbehaviours" from their compiler. As time passes and their
> experiences grow, they start to like some of the side effects, and as
> maturity reaches them, they are already *relying* on them. C/C++
> undefined behaviour and Perl's utter disregard for clarity are some of
> the examples.
>
> Chandler said something at the last US LLVM meeting that stuck with
> me: "you guys expect hardware to behave in ways that hardware can't".
> Undefined behaviour and implementation defined features in the C/C++
> standards is what it is, on purpose. If it wasn't for that, C/C++
> couldn't perform well on most hardware architectures of today.

I fear that this:

> Programmers *must* learn not to rely on their particular desires or
> compilers, to understand the language for what it is, and to exploit
> its perks while still being platform independent. It is possible, but
> *very* hard.

while attractive from the compiler-writer point of view, is just not
realistic, given the enormous body of C code out there which does
depend on some particular properties which are not guaranteed by the
ISO standard.
That code is not necessarily all gospel, of course, far from it - but
its existence does have to be taken seriously.

Peter



>> Ideally together with the compiler there would be a static analyzer with the
>> invariant that it finds all situations where the compiler, while compiling,
>> optimizes based on UB. This static analyzer would report in an intelligible
>> way on all such situations. Unfortunately this is a really hard problem.
>
> And that's why you have static analyser tools! Lints, checks,
> sanitizers, warnings and error messages are all there to make you into
> a better programmer, so you can learn about the language, and how to
> use your compiler.
>
> Ultimately, compilers are tools. The sharper they get, the more
> carefully you need to handle it. They also have a safety trigger: it's
> called -O0.
>
> cheers,
> --renato