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
