Re: [PATCH 1/2] explicit_bzero-tests: pacify GCC

[Bruno Haible]

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