haoNoQ wrote: We could also go with something like "uninitialized or inaccessible memory" so that to technically cover the OOB case without triggering an immediate visceral reaction to buffer overruns. But it'll probably still be net-negative in confusion compared to a simple "uninitialized".
FWIW, if we feel like we're in no position to go for the stronger "uninitialized" message just yet, I'm completely open to landing the initial version of the patch. I think it's even ok to let go of the "and not meaningful" part and simply stick to hard facts: "Assigned value is undefined" period. "Undefined" is the official term so there's no risk of running into a euphemism treadmill. > In general, I think it is desirable to report a problem about undefined > behavior as close to its cause as possible, using a logical explanation where > possible. It is absolutely the goal, yes. But because there's so much *emergent behavior* in our tool, we don't always have that luxury. It is often very valuable to accurately explain the tool's actual "thought process" first, jump to conclusions later. https://github.com/llvm/llvm-project/pull/126596 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
