Re: C as used/implemented in practice: analysis of responses

[Andreas Hollmann <hollmann at in dot tum dot de>]

There is some recent code added to Linux 4.2, that relies on disabled
optimization.
This might be an interesting case of unclear interpretation/misuse of
the C language.

#ifdef __OPTIMIZE__
 #error "The CPU Jitter random number generator must not be compiled
with optimizations.
See documentation. Use the compiler switch -O0 for compiling jitterentropy.c."
#endif

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/crypto/jitterentropy.c

Documentation: http://www.chronox.de/jent/doc/CPU-Jitter-NPTRNG.html

2015-06-27 1:48 GMT+02:00 Peter Sewell <Peter.Sewell@cl.cam.ac.uk>:
> On 26 June 2015 at 20:27, Joseph Myers <joseph@codesourcery.com> wrote:
>> On Fri, 26 Jun 2015, Peter Sewell wrote:
>>
>>> > It's s simple matter of points-to analysis.  &foo + anything may be
>>> > assumed (in practice) to point to something within foo (or just past the
>>> > end) and not to alias anything accessed through a pointer based on &bar.
>>> > If the compiler can see something like &foo + (&bar - &foo) there is no
>>> > guarantee of whether it will assume it to point within foo or bar and that
>>> > may not be consistent for different uses (so it may end up concluding the
>>> > pointer compares unequal to itself).
>>>
>>> Ok, that's fine in some (perhaps most) situations, but it's not
>>> compatible with what seems to be a significant body of systems code
>>> out there - people mentioned important usages in FreeBSD, Linux, QEMU,
>>> and other places. How can these be reconciled?  We imagine:
>>
>> Does that code actually access the same object via both routes in code
>> that might get moved past each other (or values get reused because the
>> compiler didn't think they could have changed) as a consequence of the
>> points-to analysis?  If the aliasing isn't visible, it's less likely to
>> cause problems.
>
> It's a good question - quite possibly not, though it's hard to
> investigate; really we have no idea.   But I'm not sure how we could
> state a condition like that precisely in some reasonable way, and if
> the conditions under which this is safe become too complex, that in
> itself becomes a failing in the language definition - at the end of
> the day, it has to be comprehensible.
>
> More generally, the programming-language design tradeoff between
> simplicity on the one hand and performance and expressivity on the
> other is always a difficult thing to manage.  The wide range of
> opinions out there about what C behaviour can be relied on suggests
> that C may have veered too far to the latter in some respects.
>
>>> a) Compilation of that systems code could turn off this analysis (and
>>> whatever optimisation depends on it) entirely.  What's the cheapest
>>> way to do that?
>>
>> I think -fno-tree-pta should disable it (I don't know what the cost of
>> that is).
>
> thanks,
> Peter
>
>
>> --
>> Joseph S. Myers
>> joseph@codesourcery.com