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).
Reply to: