Marco Leise <Marco.Leise@gmx.de> wrote:
> Am Mon, 07 Apr 2014 23:28:02 +0000
> schrieb "w0rp" <devw0rp@gmail.com>:
> 
>> http://heartbleed.com/
>> 
>> This bug has been getting around. The bug was caused by missing bounds checking.
>> 
>> I'm glad to be using a language with bounds checking.
> 
> 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?"
> 
> 
> (The attacker could request a larger packet size than required
> for the requested data and malloc() doesn't zero out the rest
> of the memory block, possibly containing sensitive data.)

As far as I understand it, you can read up to 64 KB of data, much more than the typical 4 KB block size. That means that you can read adjacent memory blocks that possibly contain perfectly valid data.

Tobi

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 [...]

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.

-- 
Marco

On Wed, 09 Apr 2014 13:35:43 -0400, David Nadlinger <code@klickverbot.at> wrote:

> On Tuesday, 8 April 2014 at 20:50:35 UTC, Steven Schveighoffer wrote:
>> This does not sound correct. In NO case should you be able to remove bounds checking in @safe code.
>
> It is. In fact, that's the very reason why DMD has -noboundscheck in addition to -release.

I meant correct as in not wrong, not correct as in the current state of the compiler :)

Otherwise, @safe is just another meaningless convention. Walter?

-Steve

On Thursday, 10 April 2014 at 14:13:30 UTC, Steven Schveighoffer wrote:
> On Wed, 09 Apr 2014 13:35:43 -0400, David Nadlinger <code@klickverbot.at> wrote:
>
>> On Tuesday, 8 April 2014 at 20:50:35 UTC, Steven Schveighoffer wrote:
>>> This does not sound correct. In NO case should you be able to remove bounds checking in @safe code.
>>
>> It is. In fact, that's the very reason why DMD has -noboundscheck in addition to -release.
>
> I meant correct as in not wrong, not correct as in the current state of the compiler :)
>
> Otherwise, @safe is just another meaningless convention. Walter?
>
> -Steve

It's funny because just the other day I tried argue on Rust mailing list why -noboundscheck flag should be added to the Rust compiler. My argument didn't go down very well. But my point was that someone at some point might have a genuine need for that flag, and that having the option to compile the code to an unsafe program doesn't make the language itself any less safe.

@safe guarantees memory-safety given that any @trusted code used doesn't break its promise and that you don't use the -noboundscheck flag. That doesn't sound like a convention to me.

On Thursday, 10 April 2014 at 14:13:30 UTC, Steven Schveighoffer
wrote:
> On Wed, 09 Apr 2014 13:35:43 -0400, David Nadlinger <code@klickverbot.at> wrote:
>
>> On Tuesday, 8 April 2014 at 20:50:35 UTC, Steven Schveighoffer wrote:
>>> This does not sound correct. In NO case should you be able to remove bounds checking in @safe code.
>>
>> It is. In fact, that's the very reason why DMD has -noboundscheck in addition to -release.
>
> I meant correct as in not wrong, not correct as in the current state of the compiler :)
>
> Otherwise, @safe is just another meaningless convention. Walter?
>
> -Steve

It's funny because just the other day I tried argue on Rust
mailing list why -noboundscheck flag should be added to the Rust
compiler. My argument didn't go down very well. But my point was
that someone at some point might have a genuine need for that
flag, and that having the option to compile the code to an unsafe
program doesn't make the language itself any less safe.

@safe guarantees memory-safety given that any @trusted code used
doesn't break its promise and that you don't use the
-noboundscheck flag. That doesn't sound like a convention to me.

On Thu, 10 Apr 2014 10:55:26 -0400, Tommi <tommitissari@hotmail.com> wrote:

> On Thursday, 10 April 2014 at 14:13:30 UTC, Steven Schveighoffer wrote:
>> On Wed, 09 Apr 2014 13:35:43 -0400, David Nadlinger <code@klickverbot.at> wrote:
>>
>>> On Tuesday, 8 April 2014 at 20:50:35 UTC, Steven Schveighoffer wrote:
>>>> This does not sound correct. In NO case should you be able to remove bounds checking in @safe code.
>>>
>>> It is. In fact, that's the very reason why DMD has -noboundscheck in addition to -release.
>>
>> I meant correct as in not wrong, not correct as in the current state of the compiler :)
>>
>> Otherwise, @safe is just another meaningless convention. Walter?
>>
>> -Steve
>
> It's funny because just the other day I tried argue on Rust mailing list why -noboundscheck flag should be added to the Rust compiler. My argument didn't go down very well. But my point was that someone at some point might have a genuine need for that flag, and that having the option to compile the code to an unsafe program doesn't make the language itself any less safe.
>
> @safe guarantees memory-safety given that any @trusted code used doesn't break its promise and that you don't use the -noboundscheck flag. That doesn't sound like a convention to me.

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 a -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 want to eliminate bounds checks, use @trusted.

-Steve

On Thursday, 10 April 2014 at 15:00:34 UTC, Steven Schveighoffer wrote:
> On Thu, 10 Apr 2014 10:55:26 -0400, Tommi <tommitissari@hotmail.com> wrote:
>
>> On Thursday, 10 April 2014 at 14:13:30 UTC, Steven Schveighoffer wrote:
>>> On Wed, 09 Apr 2014 13:35:43 -0400, David Nadlinger <code@klickverbot.at> wrote:
>>>
>>>> On Tuesday, 8 April 2014 at 20:50:35 UTC, Steven Schveighoffer wrote:
>>>>> This does not sound correct. In NO case should you be able to remove bounds checking in @safe code.
>>>>
>>>> It is. In fact, that's the very reason why DMD has -noboundscheck in addition to -release.
>>>
>>> I meant correct as in not wrong, not correct as in the current state of the compiler :)
>>>
>>> Otherwise, @safe is just another meaningless convention. Walter?
>>>
>>> -Steve
>>
>> It's funny because just the other day I tried argue on Rust mailing list why -noboundscheck flag should be added to the Rust compiler. My argument didn't go down very well. But my point was that someone at some point might have a genuine need for that flag, and that having the option to compile the code to an unsafe program doesn't make the language itself any less safe.
>>
>> @safe guarantees memory-safety given that any @trusted code used doesn't break its promise and that you don't use the -noboundscheck flag. That doesn't sound like a convention to me.
>
> 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 a -compilergeneratedhash switch that overrides any toHash functions with a compiler generated one. You are changing the agreement between the compiler and the code.

Obviously if such or any other compiler flags exist, their existence and behaviour has been specified in binding agreement between the compiler and the source code, and thus, no breach of contract has happened if such compiler flags were used.

On Thu, 10 Apr 2014 12:49:26 -0400, Tommi <tommitissari@hotmail.com> wrote:

> On Thursday, 10 April 2014 at 15:00:34 UTC, Steven Schveighoffer wrote:

>> 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 a -compilergeneratedhash switch that overrides any toHash functions with a compiler generated one. You are changing the agreement between the compiler and the code.
>
> Obviously if such or any other compiler flags exist, their existence and behaviour has been specified in binding agreement between the compiler and the source code, and thus, no breach of contract has happened if such compiler flags were used.

A compiler flag is a blunt instrument. It affects all code the compiler touches, which may or may not affect code that you are intending to change.

For example:

// compiled without -noboundscheck
module compiledlib;

void foo(T)(T[] x) @safe
{
   x[5] = 3;
}

...

// compiled with -noboundscheck
main() @safe
{
   foo([1,2,3]); // memory now corrupted, no warning, no runtime error.
}

-Steve

Steven Schveighoffer:

> No, the author of the @safe code expects bounds checking, it's part of the requirements.

Take a look ad Ada language. It has bounds checking and its compilers have a switch to disable those checks. If you want the bounds checking don't use the switch that disables the bounds checking. Safety doesn't mean to have no way to work around safety locks. It means have nice handy locks that are active on default. In a system language total safety is an illusion. Better to focus on real world safety and not a illusion of theoretical safety.

Bye,
bearophile