qemu-devel
[Top][All Lists]
Advanced

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

Re: macOS (Big Sur, Apple Silicon) 'make check' fails in test-crypto-tls


From: Christian Schoenebeck
Subject: Re: macOS (Big Sur, Apple Silicon) 'make check' fails in test-crypto-tlscredsx509
Date: Tue, 02 Feb 2021 17:35:49 +0100

On Dienstag, 2. Februar 2021 15:50:24 CET Eric Blake wrote:
> > If the program is compiled with -O0/O1 it returns zero exit code.
> > Here's the output:
> > IO
> > func1:16 foo: 0x0 counter 10
> > func2:4 foo: 0xa
> > good
> > 
> > If it is compiled with -O2 it returns 1:
> > IO
> > func1:16 foo: 0x0 counter 10
> > func2:4 foo: 0xa
> > func2:6 foo: 0x0
> 
> And this proves the point that the compiler was able to exploit the
> undefined behavior in your program.
> 
> > broken
> > 
> > That happens because clang uses register behind foo from func1 (it has
> > zero
> > pointer) inside inlined func2 (it should have non zero pointer).
> > 
> > So, immediate workaround would be to downgrade optimization level of
> > libtasn1 to -O1 in homebrew.
> > 
> > I've submitted the issue to Apple bugtracker:
> > FB8986815
> 
> Yes, it's annoying that as compilers get smarter, it exposes the
> presence of unspecified code in weird ways.  But I don't see this as a
> bug in clang, but as a bug in libtasn1 for assuming undefined behavior
> produces a sane result.

You are right Eric, but nevertheless it's a very aggressive behaviour change 
being introduced way too silent, especially regarding backward compatibility 
like this case proofs.

Personally I find the new semantic NULL + n == NULL makes sense, as it adds 
safety, but I do consider it a bug that clang did not even throw a warning. 
Even when I add -Wnull-pointer-arithmetic it does not complain to me at all.

Best regards,
Christian Schoenebeck





reply via email to

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