On Saturday, 2 August 2014 at 19:10:51 UTC, Walter Bright wrote:
On 8/2/2014 4:12 AM, Artur Skawina via Digitalmars-d wrote:
_`assume` is extremely dangerous_. Redefining `assert` to
include `assume`
would result in D's `assert` being banned from the whole code
base, if 'D'
even would be consider a 'sane' enough language to use...
More simply, you could just ban "-release".
Keep in mind, that under the current implementation, removing
asserts also removes the bug checking that the asserts
presumably were inserted for. If the asserts don't hold true,
the program has undetected bugs in it, it is in an unknown and
invalid state, and the ability to predict what it will do next
is gone.
I.e. you should already have banned use of "-release".
There's a huge difference between removing an extra check to
verify the lack of a bug versus guaranteeing the lack of a bug
and optimizing off of it. The way that assert is traditionally
used (C/C++, Java, C#, current D implementation, etc) is a
verification of your code, not a hint to the optimizer that some
expression is true. If D wishes to change this meaning then it
goes against D's philosophy of that if C code compiles it should
behave the same way as it did in C, and goes against every
previous usage of assert. Worse, it does so in a way that would
be extremely hard to detect if tests don't catch it since the
error would occur in an unrelated location and only in release
builds.
More importantly, it's a huge security flaw. Not all bugs are
equal; an assertion being false means a bug exists, but
optimizing based off of this allows much more severe bugs to
exist. Given a function that makes a call to a database/launches
a process/returns some HTML/etc, having an early check that
directly or indirectly asserts the data is valid to ease
debugging will remove the runtime check that ensures there's
nothing malicious in that data. Now because you had one extra
assert, you have a huge security flaw and a great deal of unhappy
customers that have had their accounts compromised or their
information leaked. This is not an unrealistic scenario.
That being said, so long as this is a separate optimization
switch, it should rarely be an issue. Keep the current behaviour
of -release disabling asserts, then add a new -assumeasserts or
-Oassert or such that allows the optimizer to optimize with the
guarantee that all asserts are true. It would also be good to be
able to guarantee that some piece of code can never be optimized
out (e.g., sanitation of user input). Changing the current
behaviour of -release is a huge breaking change that would open
up security holes and overall I feel would be a terrible thing to
do.
