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

[Renato Golin]

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.
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.


> 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