[LLVMdev] C as used/implemented in practice: analysis of responses (original) (raw)

Peter Sewell Peter.Sewell at cl.cam.ac.uk
Wed Jul 1 05:10:00 PDT 2015

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

More information about the llvm-dev mailing list