On 2/2/21 10:35 AM, Christian Schoenebeck wrote: >>> 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.
Yes, you do have a valid argument: any compiler that is going to optimize on our undefined behavior, but fails to give us a -Wxyz option to ferret out those spots in our code in order to avoid them in the first place, has a poor QoI, and it is worth filing a bug against that compiler to have it not be so silent. Or put another way, there is a subtle difference between arguing that "the compiler is miscompiling my program" (which is demonstrably false per the standard's permission for the compiler to do whatever it wants on undefined code, but if true would represent a regression) and "the compiler is not helping me eradicate undefined behavior from my dusty-deck code" (which is demonstrably true), and the latter is definitely worthy of being designated a clang bug (but not regression, rather, you just got lucky that your code previously did what you wanted in spite of its undefinedness). And that applies whether or not we also pursue the parallel course of action of fixing the actual undefined-code bug in libtasn1 that triggered this discussion. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3226 Virtualization: qemu.org | libvirt.org
