On Wed, 16 Aug 2023, Siddhesh Poyarekar wrote:
> No I understood the distinction you're trying to make, I just wanted to point > out that the effect isn't all that different. The intent of the wording is > not to prescribe a solution, but to describe what the compiler cannot do and > hence, users must find a way to do this. I think we have a consensus on this > part of the wording though because we're not really responsible for the > prescription here and I'm happy with just asking users to sandbox. Nice! > I suppose it's kinda like saying "don't try this at home". You know many will > and some will break their leg while others will come out of it feeling > invincible. Our job is to let them know that they will likely break their leg > :) Continuing this analogy, I was protesting against doing our job by telling users "when trying this at home, make sure to wear vibranium shielding" while knowing for sure that nobody can, in fact, obtain said shielding, making our statement not helpful and rather tautological. > How about this in the last section titled "Security features implemented in > GCC", since that's where we also deal with security hardening. > > Similarly, GCC may transform code in a way that the correctness of > the expressed algorithm is preserved but supplementary properties > that are observable only outside the program or through a > vulnerability in the program, may not be preserved. This is not a > security issue in GCC and in such cases, the vulnerability that > caused exposure of the supplementary properties must be fixed. Yeah, indicating scenarios that fall outside of intended guarantees should be helpful. I feel the exact text quoted above will be hard to decipher without knowing the discussion that led to it. Some sort of supplementary section with examples might help there. In any case, I hope further discussion, clarification and wordsmithing goes productively for you both here on the list and during the Cauldron. Thanks. Alexander
