|
From: | Paul Eggert |
Subject: | Re: [PATCH 1/2] explicit_bzero-tests: pacify GCC |
Date: | Sun, 18 Jul 2021 14:14:57 -0500 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 |
On 7/18/21 4:12 AM, Bruno Haible wrote:
The purpose of the test is to verify that the compiler does not eliminate a call to explicit_bzero, even if data flow analysis reveals that the stack area is "dead" at the end of the function. With this patch, it was turned into a weaker assertion: namely, that the compiler does not eliminate a call to explicit_bzero if it cannot make inferences about the pointer argument.
Strictly speaking, neither assertion is weaker than the other. However, 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.
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.
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.
(These points are of course low-priority, as explicit_bzero is documented to be best-effort as opposed to being a guarantee that the information is erased.)
0001-explicit_bzero-tests-pacify-GCC-better.patch
Description: Text Data
[Prev in Thread] | Current Thread | [Next in Thread] |