Re: [PATCH v2 3/4] tools/tests/x86_emulator: fix undefined behaviour in shift

[Edwin Torok <edwin.torok@xxxxxxxxxx>]

> On 3 Mar 2026, at 14:09, Jan Beulich <jbeulich@xxxxxxxx> wrote:
> 
> On 03.03.2026 15:07, Jan Beulich wrote:
>> On 27.02.2026 11:58, Edwin Török wrote:
>>> --- a/tools/tests/x86_emulator/test_x86_emulator.c
>>> +++ b/tools/tests/x86_emulator/test_x86_emulator.c
>>> @@ -1100,7 +1100,7 @@ int main(int argc, char **argv)
>>>     regs.edi    = (unsigned long)res;
>>>     rc = x86_emulate(&ctxt, &emulops);
>>>     if ( (rc != X86EMUL_OKAY) ||
>>> -         (*res != ((0x2233445F << 2) | 2)) ||
>>> +         (*res != ((0x2233445FUL << 2) | 2)) ||
>> 
>> Why the L when res is an array of unsigned int? With it dropped (happy
>> to do so while committing):
>> Acked-by: Jan Beulich <jbeulich@xxxxxxxx>
> 
> I should probably add that nevertheless it's not quite clear to me what use it
> is to compile the harness source itself with sanitizer options.


I was trying to see why the tests were failing with clang, but not GCC.
That could also be because clang takes different (optimisation) decisions on 
how to handle undefined behaviour.
It turned out that undefined behaviour wasn’t the reason the results were 
different, but I sent some patches to fix
some of the (currently latent) bugs it uncovered.

> I can see that
> to be useful for the core emulator files compiled into the harness binary.
> 

For sanitisers like the memory sanitisers (which detects reads from 
uninitialized values) I think it is best to have the whole program compiled 
with it
(the uninitialised value could originate in a different file). Or at least as 
far as reasonable (I’m not rebuilding libc).
But even for the address sanitiser a buffer could be allocated (e.g. on the 
stack) in a different file than where the bug is.


Best regards,
—Edwin