Re: [Qemu-devel] [PATCH 1/2] target-i386: Use 1UL for bit shift

[Peter Maydell]

On 1 October 2015 at 18:30, Paolo Bonzini <address@hidden> wrote:
>
>
> On 01/10/2015 19:07, Laszlo Ersek wrote:
>> > In addition, C89 didn't say at all what the result was for signed data
>> > types, so technically we could compile QEMU with -std=gnu89 (the default
>> > until GCC5) and call it a day.
>> >
>> > Really the C standard should make this implementation-defined.
>>
>> Obligatory link: http://blog.regehr.org/archives/1180
>
> Many ideas in there are good (e.g. mem*() being defined for invalid
> argument and zero lengths, and of course item 7 which is the issue at
> hand).  In many cases it's also good to change undefined behavior to
> unspecified values, however I think that goes too far.
>
> For example I'm okay with signed integer overflow being undefined
> behavior, and I also disagree with "It is permissible to compute
> out-of-bounds pointer values including performing pointer arithmetic on
> the null pointer".  Using uintptr_t is just fine.

I bet you QEMU breaks the 'out of bounds pointer arithmetic'
rule all over the place. (set_prop_arraylen(), for a concrete
example off the top of my head.)

Signed integer overflow being UB is a really terrible idea which
is one of the core cases for nailing down the UB -- everybody
expects signed integers to behave as 2s-complement, when in
fact what the compiler can and will do currently is just do totally
unpredictable things...

> Also strict aliasing improves performance noticeably at least on some
> kind of code.  The relaxation of strict aliasing that GCC does with
> unions would be a useful addition to the C standard, though.

QEMU currently turns off strict-aliasing entirely, which I think
is entirely sensible of us.

A lot of the underlying intention behind the proposal (as I
interpret it) is "consistency and predictability of behaviour
for the programmer trumps pure performance". That sounds like
a good idea to me.

thanks
-- PMM