On Thu, 10 Apr 2014 19:21:52 -0400, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:

> On 4/10/14, 10:56 AM, Steven Schveighoffer wrote:
>> @safe code can be marked as @trusted instead, and nothing changes,
>> except @trusted code can have bounds checks removed. How does this not
>> work as a solution?
>
> Doesn't work because @trusted removes all additional checks by the compiler. We do want to have @safe as mechanically verified.

I think you are missing something. This is code that is marked as @safe. Then you change it to @trusted. It doesn't change that the code is @safe, but now it's @trusted so the bounds checks can be removed temporarily.

The assertion is that -noboundscheck for @safe code is a temporary condition to find possible optimizations. Then if this helps, you can find a more permanent mechanism to fix the performance. A similar mechanism is to use @trusted to allow bounds checks to go away temporarily, as a test. Any function that is @safe can be instead marked as @trusted, and nothing else changes.

>> As Walter often says about logical const, logical @safe is @safe by
>> convention, and it loses all of its teeth.
>
> I think you are wrong here.

Victims with bleeding hearts around the world are feeling the effects of logical safety.

If @safe is just a convention, then I don't see the point of having it at all. If it can't be a guarantee, then it's pretty much another tech buzzword with no teeth.

-Steve

On Friday, 11 April 2014 at 00:52:25 UTC, Steven Schveighoffer wrote:
> If @safe is just a convention, then I don't see the point of having it at all. If it can't be a guarantee, then it's pretty much another tech buzzword with no teeth.

In order to have @safe be a guarantee of memory-safety, we need to prevent @safe code from calling any @trusted code.

On 4/10/14, 5:52 PM, Steven Schveighoffer wrote:
> If @safe is just a convention, then I don't see the point of having it
> at all.

That I agree with. -- Andrei

Andrei Alexandrescu:

> Steven Schveighoffer:
>> If @safe is just a convention, then I don't see the point of having it at all.
>
> That I agree with. -- Andrei

I agree. But a safety that can be disabled only by an explicit and visible request is not a convention.

Bye,
bearophile

On Thursday, 10 April 2014 at 07:14:10 UTC, Marco Leise wrote:
> Am Thu, 10 Apr 2014 06:51:40 +0000
> schrieb "w0rp" <devw0rp@gmail.com>:
>
>> On Wednesday, 9 April 2014 at 12:36:49 UTC, Marco Leise wrote:
>> > Sorry, but wasn't this security risk instead caused by
>> > uninitialized memory, and shouldn't you instead have said:
>> >
>> > "I'm glad to be using a language with default initialization?"
>> 
>> Nope, it was caused by missing bounds checking.
>> 
>> https://www.openssl.org/news/secadv_20140407.txt
>> 
>> > A missing bounds check [...]
>
> Haha, I tried to read that about an hour ago to inform myself,
> but it still doesn't load for me.

http://blog.existentialize.com/diagnosis-of-the-openssl-heartbleed-bug.html
The server copies data received from the client and sends it back, the length is specified (or forged) by the client, everything is initialized just fine.

On Fri, 11 Apr 2014 00:01:17 -0400, Tommi <tommitissari@hotmail.com> wrote:

> On Friday, 11 April 2014 at 00:52:25 UTC, Steven Schveighoffer wrote:
>> If @safe is just a convention, then I don't see the point of having it at all. If it can't be a guarantee, then it's pretty much another tech buzzword with no teeth.
>
> In order to have @safe be a guarantee of memory-safety, we need to prevent @safe code from calling any @trusted code.

Or manually guarantee the safety of @trusted code.

I should be able to write an application with only @safe functions, and trust that phobos has implemented @trusted functions properly.

-Steve

"Steven Schveighoffer"  wrote in message news:op.xd3vzecweav7ka@stevens-macbook-pro.local...

> No, the author of the @safe code expects bounds checking, it's part of the requirements. To compile his code with it off is like having   -compilergeneratedhash switch that overrides any toHash functions with a compiler generated one. You are changing the agreement between the compiler and the code. When I say @safe, I mean "I absolutely always want bounds checks."

If you have code that would ever fail a bounds check, that is a program error, similar to code that may fail an assertion.

And like assertions, if you would rather the code was as fast as possible instead of as safe as possible you can use a compiler switch to disable bound checks.

The usual switch to do stuff like this is '-release', but because @safe functions should still have the 'no memory corruption' even in release mode, disabling those bounds checks was moved into another compiler switch.

> If you want to eliminate bounds checks, use @trusted.

No, @trusted means "don't check my code" while @safe + noboundschecks means (mostly) "only check my code at compile-time". 

On Friday, 11 April 2014 at 12:00:32 UTC, Steven Schveighoffer wrote:
> On Fri, 11 Apr 2014 00:01:17 -0400, Tommi <tommitissari@hotmail.com> wrote:
>
>> On Friday, 11 April 2014 at 00:52:25 UTC, Steven Schveighoffer wrote:
>>> If @safe is just a convention, then I don't see the point of having it at all. If it can't be a guarantee, then it's pretty much another tech buzzword with no teeth.
>>
>> In order to have @safe be a guarantee of memory-safety, we need to prevent @safe code from calling any @trusted code.
>
> Or manually guarantee the safety of @trusted code.
>
> I should be able to write an application with only @safe functions, and trust that phobos has implemented @trusted functions properly.
>
> -Steve

I was talking about @safe in general sense, not only as it pertains to phobos.

On Fri, 11 Apr 2014 08:37:59 -0400, Tommi <tommitissari@hotmail.com> wrote:

> On Friday, 11 April 2014 at 12:00:32 UTC, Steven Schveighoffer wrote:
>> On Fri, 11 Apr 2014 00:01:17 -0400, Tommi <tommitissari@hotmail.com> wrote:
>>
>>> On Friday, 11 April 2014 at 00:52:25 UTC, Steven Schveighoffer wrote:
>>>> If @safe is just a convention, then I don't see the point of having it at all. If it can't be a guarantee, then it's pretty much another tech buzzword with no teeth.
>>>
>>> In order to have @safe be a guarantee of memory-safety, we need to prevent @safe code from calling any @trusted code.
>>
>> Or manually guarantee the safety of @trusted code.
>>
>> I should be able to write an application with only @safe functions, and trust that phobos has implemented @trusted functions properly.
>
> I was talking about @safe in general sense, not only as it pertains to phobos.

@trusted code needs to be severely scrutinized, since you are turning off safety checks, no matter where the code is. My point was that if I want to ONLY write @safe code, I should be able to without fear that the @trusted functions in Phobos are susceptible to memory bugs.

The idea is that the number of functions that are @trusted is very small, so we can be extra cautious and focused with them. Then the number of @safe functions can be quite large and useful. Kind of like casts -- you should really scrutinize and focus on casts to make sure nothing untoward is happening, since the compiler is deferring to you.

One thing that kind of sucks about this, is that @safe vs. @trusted is a large bag of safety checks. If all you want is to disable array bounds checking, for maybe one or two array indexes in a large function, it's a large price to pay to mark the entire function @trusted. Inner functions help with this a bit, but maybe one should be able to mark an expression as @trusted inside a @safe function. Give the developer a scalpel instead of a saws-all.

-Steve

On Fri, 11 Apr 2014 08:35:07 -0400, Daniel Murphy <yebbliesnospam@gmail.com> wrote:

> "Steven Schveighoffer"  wrote in message news:op.xd3vzecweav7ka@stevens-macbook-pro.local...
>
>> No, the author of the @safe code expects bounds checking, it's part of the requirements. To compile his code with it off is like having   -compilergeneratedhash switch that overrides any toHash functions with a compiler generated one. You are changing the agreement between the compiler and the code. When I say @safe, I mean "I absolutely always want bounds checks."
>
> If you have code that would ever fail a bounds check, that is a program error, similar to code that may fail an assertion.
>
> And like assertions, if you would rather the code was as fast as possible instead of as safe as possible you can use a compiler switch to disable bound checks.
>
> The usual switch to do stuff like this is '-release', but because @safe functions should still have the 'no memory corruption' even in release mode, disabling those bounds checks was moved into another compiler switch.
>
>> If you want to eliminate bounds checks, use @trusted.
>
> No, @trusted means "don't check my code" while @safe + noboundschecks means (mostly) "only check my code at compile-time".

Here is the horror scenario I envision:

1. Company has 100kLOC project, which is marked as @safe (I can dream, can't I?)
2. They find that performance is lacking, maybe compared to a competitor's C++ based code.
3. They try compiling with -noboundscheck, get a large performance boost. It really only makes a difference in one function (the inner loop one).
4. They pat themselves on the back, and release with the new flag, destroying all bounds checks, even bounds checks in library template code that they didn't write or scrutinize.
5. Buffer overflow attacks abound.
6. D @safe is labeled a "joke"

But there is a cost, even to labeling the "one inner" function @trusted. Perhaps that function is extremely long and complex. There should be a way to say, "I still want all the @safety checks, except for this one critical array access, I have manually guaranteed the bounds". We don't have anything like that. All other safety checks are really static, this is the only runtime penalty for safety.

The blunt flag approach is scary. @trusted is better, in that you can focus on one function at a time. But I think we need something more precise. Perhaps you should be able to have @trusted scopes, or @trusted expressions.

-Steve