> -release leaves bounds checking on. Use -noboundscheck to turn off bounds checking.

But only for @safe functions. I want it on for all functions.

On 4/7/14, 11:17 PM, Orvid King wrote:
> On Mon, 07 Apr 2014 20:59:50 -0500, Ary Borenszweig
> <ary@esperanto.org.ar> wrote:
>
>> On 4/7/14, 8:28 PM, w0rp wrote:
>>> 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.
>>
>> http://www.reddit.com/r/programming/comments/21m0bz/warp_a_fast_c_and_c_preprocessor/cged2y6
>>
>>
>> I think that flag shouldn't exist.
>>
>
> The bad thing is, I have some code that having bounds checks enabled
> actually improves the speed of.

Yes, it happened to me too (using another language). I was really surprised.

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.

In regards to Turbo Pascal and successors, there is hardly any C design decision I agree with.

--
Paulo

On 4/7/2014 10:50 PM, Nick Sabalausky wrote:
> On 4/7/2014 10:17 PM, Orvid King wrote:
>>
>> The bad thing is, I have some code that having bounds checks enabled
>> actually improves the speed of.
>
> Not surprised, but I imagine it's likely only a handful of places where
> the bounds checking is actually slowing things down noticeably.

Nevermind, I clearly misread your post :)

On Tuesday, 8 April 2014 at 08:22:09 UTC, Andrej Mitrovic wrote:
> On 4/8/14, w0rp <devw0rp@gmail.com> wrote:
>> http://heartbleed.com/
>
> Is there a link to a specific section of code where this bug is
> introduced? That page is massive and all I want to do is see the buggy
> code. :>

http://blog.existentialize.com/diagnosis-of-the-openssl-heartbleed-bug.html

Hope that helps :-).

On Tue, 08 Apr 2014 04:50:29 -0400, Paulo Pinto <pjmlp@progtools.org> wrote:

> On Tuesday, 8 April 2014 at 01:59:50 UTC, Ary Borenszweig wrote:
>> On 4/7/14, 8:28 PM, w0rp wrote:
>>> 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.
>>
>> http://www.reddit.com/r/programming/comments/21m0bz/warp_a_fast_c_and_c_preprocessor/cged2y6
>>
>> I think that flag shouldn't exist.
>
> Personally I think it should exist, but in a more controlled way, a compiler pragma.
>
> For example Turbo Pascal has something like {$R -} code {$R +}.

Note, you can disable bounds checking on an expression basis by replacing this:

arr[x]

with this:

arr.ptr[x]

The only tricky part is if you have to slice, and you are using $:

arr.ptr[x..$]

doesn't work, you have to use:

arr.ptr[x..arr.length]

-Steve

On Tue, Apr 08, 2014 at 02:46:57AM -0700, 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.

And just yesterday, I caught yet another long-standing off-by-1 array overrun bug in the C code I was working on at work, that obviously nobody else noticed. Sigh...


T

-- 
War doesn't prove who's right, just who's left. -- BSD Games' Fortune

Am 08.04.2014 16:57, schrieb Steven Schveighoffer:
> On Tue, 08 Apr 2014 04:50:29 -0400, Paulo Pinto <pjmlp@progtools.org>
> wrote:
>
>> On Tuesday, 8 April 2014 at 01:59:50 UTC, Ary Borenszweig wrote:
>>> On 4/7/14, 8:28 PM, w0rp wrote:
>>>> 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.
>>>
>>> http://www.reddit.com/r/programming/comments/21m0bz/warp_a_fast_c_and_c_preprocessor/cged2y6
>>>
>>>
>>> I think that flag shouldn't exist.
>>
>> Personally I think it should exist, but in a more controlled way, a
>> compiler pragma.
>>
>> For example Turbo Pascal has something like {$R -} code {$R +}.
>
> Note, you can disable bounds checking on an expression basis by
> replacing this:
>
> arr[x]
>
> with this:
>
> arr.ptr[x]
>
> The only tricky part is if you have to slice, and you are using $:
>
> arr.ptr[x..$]
>
> doesn't work, you have to use:
>
> arr.ptr[x..arr.length]
>
> -Steve

Is that only allowed in @system?

--
Paulo

On Tue, 08 Apr 2014 11:55:35 -0400, Paulo Pinto <pjmlp@progtools.org> wrote:

> Am 08.04.2014 16:57, schrieb Steven Schveighoffer:
>> Note, you can disable bounds checking on an expression basis by
>> replacing this:
>>
>> arr[x]
>>
>> with this:
>>
>> arr.ptr[x]
>>
>> The only tricky part is if you have to slice, and you are using $:
>>
>> arr.ptr[x..$]
>>
>> doesn't work, you have to use:
>>
>> arr.ptr[x..arr.length]
>>
>
> Is that only allowed in @system?

Probably. Is that an issue? Disabling bounds-checking in @safe code is a bad idea.

-Steve

Am 08.04.2014 18:20, schrieb Steven Schveighoffer:
> On Tue, 08 Apr 2014 11:55:35 -0400, Paulo Pinto <pjmlp@progtools.org>
> wrote:
>
>> Am 08.04.2014 16:57, schrieb Steven Schveighoffer:
>>> Note, you can disable bounds checking on an expression basis by
>>> replacing this:
>>>
>>> arr[x]
>>>
>>> with this:
>>>
>>> arr.ptr[x]
>>>
>>> The only tricky part is if you have to slice, and you are using $:
>>>
>>> arr.ptr[x..$]
>>>
>>> doesn't work, you have to use:
>>>
>>> arr.ptr[x..arr.length]
>>>
>>
>> Is that only allowed in @system?
>
> Probably. Is that an issue? Disabling bounds-checking in @safe code is a
> bad idea.
>
> -Steve

Completely agree. I expressed myself badly.

I think it should only be allowed in @system code.

--
Paulo