qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PULL 0/9] Misc patches for QEMU 2.5-rc2 (2015-11-25)


From: Markus Armbruster
Subject: Re: [Qemu-devel] [PULL 0/9] Misc patches for QEMU 2.5-rc2 (2015-11-25)
Date: Thu, 26 Nov 2015 13:15:13 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)

Peter Maydell <address@hidden> writes:

> On 26 November 2015 at 11:23, Paolo Bonzini <address@hidden> wrote:
>> On 26/11/2015 11:56, Peter Maydell wrote:
>>> It makes a claim about the semantics that the compiler
>>> guarantees us which isn't currently valid. (Or
>>> alternatively, it's implicitly claiming that clang isn't
>>> a supported compiler, which isn't true.) I don't think
>>> we should document or rely on signed-shift semantics
>>
>> But we are relying on them, and thus we should document them.  Witness
>> the number of patches fixing so called "undefined" behavior.  And those
>> patches are _dangerous_.

I'm pretty sure us screwing some of them up is a much larger risk than
gcc suddenly starting to screw up our signed shifts without anybody
noticing.

If gcc ever started to mess up signed shifts, I'd fully expect the
kernel and many applications to go down in flames.  Hopefully quickly
enough to avoid real damage.  I don't think gcc has become *that*
reckless.  Clang neither.

> Until and unless the compiler guarantees us the semantics that
> we want, then silently hoping we get something we're not getting
> is even more dangerous, and avoiding the UB is better than
> just crossing our fingers and hoping.

The cost and risk of proactively fixing a hypothetical^Wlatent problem
needs to be weighed against the probability of it ever becoming real.

>> I can certainly remove the "as documented by the GCC manual" part and
>> the -fwrapv setting, but silencing -Wshift-negative-value and
>> documenting what we rely on should go in.
>
> I don't see much point in documenting what we rely on
> if we can't rely on it and need to stop relying on it.

"Can't" and "need" are too strong.  The kernel can, and I fail to see
what makes us so special that we absolutely cannot.

For what it's worth, I'm sick and tired of patches "fixing" signed
shifts, and the unnecessary risk that comes with them.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]