Paul Eggert wrote:
> I take your point that the patch changes the meaning of the test in an
> undesirable way. I installed the attached to implement your suggestion.
Thank you.
> This new diagnostic points out a problem with the test, though. If GCC
> can determine that memcmp reads uninitialized storage, GCC can optimize
> away the memcmp and act as if memcmp returns 0 (or any other constant).
> So the test as it stands is problematic given recent advances in
> practical compilers.
Such compiler optimizations would need to be backed by the standards.
Are there initiatives to "outlaw" references to uninitialized storage
in recent C or C++ standards?
I hope code such as
int x; /* uninitialized */
if (!((x & 1) == 0 || (x & 1) == 1))
abort ();
will never crash. x & 1 can only be 0 or 1. Tertium not datur.
Also, I think the danger is small: GCC does not _know_ that the array
is uninitialized. It's only a "maybe uninitialized". If GCC ever
infers that it is "certainly uninitialized", we could defeat that
through a use of 'volatile', such as
int (* volatile memcmp_func) (const void *, const void *, size_t) = memcmp;
> As an aside, I don't understand the discussion of asynchronous signal
> invocations in that test's commentary. There is no asynchronous
> signaling in that code.
In some operating systems, interrupt handling uses the stack of the
currently executing thread. While this is not the case in Linux [1],
it was definitely the case in Atari TOS, and is still probably the
case in some embedded OSes for MMU-less CPUs.
Bruno
[1]
https://stackoverflow.com/questions/28759227/which-stack-is-used-by-interrupt-handler-linux
