On Fri, Jan 1, 2016, at 11:25 PM, Chris Lattner via swift-evolution wrote: > > On Dec 31, 2015, at 1:56 PM, Dave Abrahams <dabrah...@apple.com> wrote: > >>> 2) Adding asserts to code should not make the code more dangerous > >>> whatever the build. Assuming the truth of the assert may lead to runtime > >>> safety checks being skipped and undefined behaviour when a no-op would be > >>> a safe behaviour. > >> > >> This only affects code built with -Ounchecked, which is definitely not a > >> safe mode to build your code. The intention of this mode is that you can > >> use it to get a performance boost, if you believe your code to be > >> sufficiently tested. This mode, which isn’t the default in any way, > >> intentionally takes the guard rails off to get better performance. > >> > >> If you don’t like that model, don’t use this mode. > > > > Let’s just consider -O; I think I understand Joseph’s objection here, and > > it seems valid. > > Ah, good point. > > > Normally in -O, we say that if you stay in the “safe subset” of Swift code, > > you never get undefined behavior, even if there’s a bug in your code. You > > might get *unpredictable* behavior of course, but presumably guaranteeing > > no undefined behavior rules out large classes of problems, including many > > security holes. Now suppose you decide to be responsible and add some > > asserts to help you catch bugs during development. Hopefully they help you > > catch all the bugs, but what if they don’t? All of a sudden, if you still > > have a bug when you ship, you now have undefined behavior. As much as I’m > > a fan of assertions having optimization benefits, It seems a little > > perverse that using them could make shipping code less secure. > > Yes, I agree. -O should not imply undefined behavior in the case of an > assert() predicate being dynamically false. > > It sounds like we just need a documentation update here?
assert() and assertionFailure() are already explicitly documented as doing nothing in -O builds, and only making the assumption that the condition is always true/function is never called in -Ounchecked builds. As far as I can tell, the only actual inaccuracy in the documentation is the fact that assert() claims that the optimizer may assume the condition is always true in -Ounchecked when it doesn't seem to actually do that (because it doesn't do anything at all when not using -Onone). Both assert() and assertionFailure() do nothing in -O, which matches the documentation. -Kevin Ballard _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
