https://issues.dlang.org/show_bug.cgi?id=19916
--- Comment #19 from ag0aep6g <[email protected]> --- (In reply to Dennis from comment #17) > If you don't agree with the 'insufficient to corrupt memory' regime, please > propose a new one! The spec is pretty informal currently. If you have a > better interpretation, I'm eager to hear it. So far I've only heard 'things > any sane security engineer is wary of'. Per the spec (<https://dlang.org/spec/function.html#function-safety>), @safe functions "are functions that are statically checked to exhibit no possibility of undefined behavior". I suppose that's equivalent to "doesn't corrupt memory". Memory corruption is always a symptom of undefined behavior, and there is no kind of undefined behavior that doesn't potentially lead to memory corruption (or it wouldn't really be UB). I prefer focusing on undefined behavior, though. It feels more more clear cut to me. When the spec says that something has UB, then it can't be in @safe. Period. Otherwise, when the focus is on memory corruption, there's more (perceived) wiggle room. We're tempted to allow anything that doesn't lead to memory corruption in practice, even if has undefined behavior. That quickly gets messy. (In reply to Manu from comment #18) > Uninitialised memory is ALREADY CORRUPTED. There is no world where access to > what can be confirmed to be uninitialised memory is @safe, period. > > Any interaction with uninitialised memory will guarantee unintended > consequences, which could be anything. > > It's very simple; if you're going to use unions, or uninitialised memory, > then do so carefully, and @trusted that block of code. You might want to argue your position in <https://github.com/dlang/dlang.org/pull/2260>. It's an open PR by Walter where he does exactly what you oppose here: he wants to explicitly allow accessing uninitialized memory in @safe code (unless it involves pointers). --
