checkedint call removal

[Kapps via Digitalmars-d]

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.