On Wed, 6 Apr 2005 00:51:58 +0000 (UTC), <derick_eddington@yamoooo.com> wrote:
> In article <d2uj5q$2hoh$1@digitaldaemon.com>, Stewart Gordon says...
>>
>> derick_eddington@place.com wrote:
>>> In article <9jq8i2-arr.ln1@lnews.kuehne.cn>, Thomas Kuehne says...
>>>
>>>> http://digitalmars.com/d/arrays.html
>>>> # A program may not rely on array bounds checking happening.
>>>>
>>>> Unless the quote some lines lower is implemented, the quote above should
>>>> be changed to "can rely on" ?
>>
>> By "may not rely on", it means that a program that needs ABC turned on
>> in order to work correctly is incorrectly written.  As such, it will not
>> work when compiled in release mode.
>>
>>>> #  Insertion of array bounds checking code at runtime should be turned
>>>> #  on and off with a compile time switch.
>>
>> That switch is -release.  At least in the current DMD design.
>>
>>> I remember reading that, but if bounds checking is turned on and the double
>>> slice bounds checks, I think the other should.  I like the idea of having the
>>> option of turning on and off bounds checking, but I would think bounds checking
>>> should also be a feature that you can rely on to work comprehensively and
>>> consistently when it is turned on
>>
>> Entirely agreed.
>>
>>> and be a feature to use in release/production code.  Why only go half way?
>>
>> Disagreed.  ABC is left out of release builds for the same reason DBC is
>> - because it is intended for checking that the program is working
>> correctly, and having it in production code would slow the program down.
>>  As such, programs are supposed to be written so that array indexes
>> will never be out of bounds.
>>
>> Stewart.
>
> I think having the switch which disables ABC and DBC be called -release is fine.
> What I meant was that if you want to have ABC turned on in your production code,
> you should be able to rely on it; not in the sense of using it to control
> program flow (like the arrays.html example) but rely on it to catch any and
> every out-of-bounds (this would mean comphrensive ABC that could be used to
> control program flow if you wanted, but I agree that's not good design).
>
> Saying one should be a good enough programmer that you never allow overflow is a
> great ideal and one I advocate but the plethora of overflow vulnerabilities says
> to me it's not being widely achieved.  If you'd like to trade performance for
> assurance, I think you should be able to; especially for programs where DBC and
> ABC won't have a large impact on performance, and for important programs that
> are exposed to a lot of untrusted input and use, I think not using -release for
> your production version and being able to count on DBC and ABC would be a great
> option and huge selling point for D.  If I'm running a financial app exposed to
> anyone and I can afford more hardware to get whatever performance I need,
> knowing I can rely on DBC and ABC would make D very attractive to me.

See the other thread of this thread, I beleive you've found a bug (or a strange 'feature'). Making this thread of this thread err.. pointless? (perhaps?)

Regan

derick_eddington@yamoooo.com wrote:
<snip>
> Saying one should be a good enough programmer that you never allow
> overflow is a great ideal and one I advocate but the plethora of
> overflow vulnerabilities says to me it's not being widely achieved.

Exactly.  That's the point of ABC - it gives you the chance to fix the
bugs causing overflow.

> If you'd like to trade performance for assurance, I think you should be able to; especially for programs where DBC and ABC won't have a large impact on performance, and for important programs that are exposed to a lot of untrusted input and use, I think not using -release for your production version and being able to count on DBC and ABC would be a great option and huge selling point for D.  If I'm running a financial app exposed to anyone and I can afford more hardware to get whatever performance I need, knowing I can rely on DBC and ABC would make D very attractive to me.

If you want to release your programs with the ABC and DBC still in, nobody's going to stop you.  But do prepare to be thrown stones at by anyone who reads your code and finds that you rely on it.

Stewart.

-- 
My e-mail is valid but not my primary mailbox.  Please keep replies on
the 'group where everyone may benefit.