Am 02.02.21 um 18:14 schrieb Eric Blake:
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.
I agree that the compiler should have given a warning. It did not even
with -Weverything.
The code uses NULL + offset constructs, so requires a fix.
https://gitlab.com/gnutls/libtasn1/-/merge_requests/71 fixes the unit
tests of libtasn1 for me, maybe also the test for QEMU which I still
have to check.
Regards,
Stefan
