Re: Packaging of static libraries

Adam Borowski writes ("Re: Packaging of static libraries"): > On Tue, Apr 12, 2016 at 02:52:33PM +0100, Ian Jackson wrote: > > I'm afraid that LTO is probably too dangerous to be used as a > > substitute for static linking. See my comments in the recent LTO > > thread here, where I referred to the problem of undefined behaviour, > > and pointed at John Regehr's blog. > > LTO is no different from just concatenating all source files and making > functions static. If your code blows after this, it is your fault not > LTO's. LTO just allows interprocedural optimizations to work between > functions that were originally in different source files. This narrative of `fault' has two very serious problems. Firstly, it is hopelessly impractical. As I have already observed here: Recently we have seen spectacular advances in compiler optimisation. Spectacular in that large swathes of existing previously-working code have been discovered, by diligent compilers, to be contrary to the published C standard, and `optimised' into non-working machine code. In fact, it turns out that there is practically no existing C code which is correct according to said standards (including C compilers themselves). Real existing code does not conform to the rules now being enforced by compilers. Indeed often it can be very hard to write new code which does conform to the rules, even if you know what the rules are and take great care. Two examples showing how C has been turned into a puzzle language: http://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=tools/libxl/libxl_event.c;h=02b39e6da8c65c033c99a22db4784de8d7aeeb7a;hb=HEAD#l458 http://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=tools/libxl/libxl_internal.h;h=005fe538c6b5529447185797cc23d898c219e897;hb=HEAD#l294 http://lists.xenproject.org/archives/html/xen-devel/2015-10/msg03340.html http://lists.xenproject.org/archives/html/xen-devel/2015-11/threads.html#00112 The second problem is that it is based on the idea that the C specification is by definition right and proper. There are two ways to evaluate the the C specification's rightness and properness. The first is to ask what the the nominal remit of the C standards bodies is. Well, it is and was to standardise existing practice. Existing practice was to use C as a kind of portable assembler; the programmer was traditionally entitled to do the kind of things which are nowadays forbidden. So the C committee has failed at its task. [1] The second is to ask what is most useful. And there again the C committee have clearly failed. We in Debian are in a good position to defend our users from the fallout from this problem. We could change our default compiler options to favour safety, and provide more traditional semantics. We would have influence upstream (for example to further advance the set of available safety options) if we cared to use it. But sadly it seems that the notion that our most basic and widely-used programming language should be one that's fit for programming in is not yet fully accepted. At the very least we should fiercely resist any further broadening of the scope of the C UB problem. Sorry if I seem cross in this email. But that's because I am. Thanks for listening. Ian. [1] Consider for example the divergence between the C89 rationale http://www.lysator.liu.se/c/rat/a.html#1-1 and what C89 actually did (initially, only on paper, but now being enforced by compilers).