On 4/8/2014 3:55 AM, Paulo Pinto wrote:
> On Tuesday, 8 April 2014 at 09:46:51 UTC, Walter Bright wrote:
>> On 4/8/2014 1:47 AM, Paulo Pinto wrote:
>>> I never got the point of not having bounds checking in C and its ilk.
>>
>> C hardly even has arrays.
>
> Yes I know, another broken design decision.

Looking at C's decisions from our perspective is a bit unfair. The only really unforgivable one, from the perspective of the times when it was designed, is the one where arrays decay to pointers when passing them to functions. This completely defeats any attempt at detecting array overflows.

Am 08.04.2014 19:18, schrieb Walter Bright:
> On 4/8/2014 3:55 AM, Paulo Pinto wrote:
>> On Tuesday, 8 April 2014 at 09:46:51 UTC, Walter Bright wrote:
>>> On 4/8/2014 1:47 AM, Paulo Pinto wrote:
>>>> I never got the point of not having bounds checking in C and its ilk.
>>>
>>> C hardly even has arrays.
>>
>> Yes I know, another broken design decision.
>
> Looking at C's decisions from our perspective is a bit unfair. The only
> really unforgivable one, from the perspective of the times when it was
> designed, is the one where arrays decay to pointers when passing them to
> functions. This completely defeats any attempt at detecting array
> overflows.
>
>

I don't consider unfair, because there were systems languages at the time like PL/I and Mesa that had bounds checking.

C designers explicitly decided against it, with the thought that developers would use lint alongside C, which even today very few do.

--
Paulo

On 4/8/2014 10:44 AM, Paulo Pinto wrote:
> C designers explicitly decided against it, with the thought that developers
> would use lint alongside C, which even today very few do.

The trouble is that C cannot be retrofitted with bounds checking because of the array decay problem.

Am 08.04.2014 20:28, schrieb Walter Bright:
> On 4/8/2014 10:44 AM, Paulo Pinto wrote:
>> C designers explicitly decided against it, with the thought that
>> developers
>> would use lint alongside C, which even today very few do.
>
> The trouble is that C cannot be retrofitted with bounds checking because
> of the array decay problem.
>

Fully agree with you.

That is why when I used to code in C at the university and my first job, I made use of warnings as errors, asserts and did a lot of defensive coding.

Having read Code Complete made me realize how I could make C more Pascal/Modula-2 like in terms of safety.

But you are right.

--
Paulo

On 4/8/2014 12:26 PM, Paulo Pinto wrote:
> But you are right.

Words to live by :-)

On 4/8/14, 1:47 AM, Paulo Pinto wrote:
> Me too am glad see bounds checking in D by default.

For the record, dmd used to remove bounds checking in -release mode. I've asked Walter to add a new flag for that, independent from -release, thus keeping release builds safer. It was the first and last time when I used "if you don't do this, I can't work on D anymore" card. True story.


Andrei

On Tuesday, 8 April 2014 at 19:47:02 UTC, Andrei Alexandrescu wrote:
> For the record, dmd used to remove bounds checking in -release mode. I've asked Walter to add a new flag for that, independent

It still does (for un-@safe functions) and there is no way to turn it on (if you don't want asserts and contracts).

On Tuesday, 8 April 2014 at 19:47:02 UTC, Andrei Alexandrescu wrote:
> On 4/8/14, 1:47 AM, Paulo Pinto wrote:
>> Me too am glad see bounds checking in D by default.
>
> For the record, dmd used to remove bounds checking in -release mode. I've asked Walter to add a new flag for that, independent from -release, thus keeping release builds safer. It was the first and last time when I used "if you don't do this, I can't work on D anymore" card. True story.
>
>
> Andrei

There is a lot of confusion about this so I looked into it.

dmd still removes bound checking in non-@safe code when you specify -release. -noboundscheck just causes it to remove bounds checking in @safe code too. This is why I think it should be renamed -nosafeboundschecking or something similar.

In dmd's source, useArrayBounds is set to 2 by default (which does bounds checking in all code). -release sets it to 1 (which only checks @safe code).  -noboundscheck sets it to 0 (which causes it to emit no bounds checking).

On Tuesday, 8 April 2014 at 20:07:30 UTC, Martin Krejcirik wrote:
> On Tuesday, 8 April 2014 at 19:47:02 UTC, Andrei Alexandrescu wrote:
>> For the record, dmd used to remove bounds checking in -release mode. I've asked Walter to add a new flag for that, independent
>
> It still does (for un-@safe functions)

I think -noboundscheck should be renamed -nosafeboundscheck because it's just confusing with the name it has. I just did a pull request yesterday to help clarify what it does in the command line help, at least, because a lot of people are confused about this.

> and there is no way to turn it on (if you don't want asserts and
> contracts).

Good point. I think perhaps a -boundscheck is in order if the -release behavior is going to stay what it is. It's a shame that the flag already means what it does because we can't just have -noboundscheck remove them in non-@safe code and a new -nosafeboundcheck do it for safe code now.

On Tue, 08 Apr 2014 16:07:53 -0400, Brad Anderson <eco@gnuk.net> wrote:

> On Tuesday, 8 April 2014 at 19:47:02 UTC, Andrei Alexandrescu wrote:
>> On 4/8/14, 1:47 AM, Paulo Pinto wrote:
>>> Me too am glad see bounds checking in D by default.
>>
>> For the record, dmd used to remove bounds checking in -release mode. I've asked Walter to add a new flag for that, independent from -release, thus keeping release builds safer. It was the first and last time when I used "if you don't do this, I can't work on D anymore" card. True story.
>>
>>
>> Andrei
>
> There is a lot of confusion about this so I looked into it.
>
> dmd still removes bound checking in non-@safe code when you specify -release. -noboundscheck just causes it to remove bounds checking in @safe code too. This is why I think it should be renamed -nosafeboundschecking or something similar.

This does not sound correct. In NO case should you be able to remove bounds checking in @safe code.

-Steve