I've been working on implementing it. After turning it on and recompiling the library and test code, it tripped and found 3 bugs in the regexp implementation - code that I have a nice test suite for that was passing.

Just goes to show, array bounds checking really is valuable! And being able to turn it off for performance code is why D is better than other languages offering bounds checks.

Walter wrote:

> I've been working on implementing it. After turning it on and recompiling the library and test code, it tripped and found 3 bugs in the regexp implementation - code that I have a nice test suite for that was passing.
>
> Just goes to show, array bounds checking really is valuable!

No surprise for people with experience in Topspeed Modula-2 which had this RT check many years ago.

> And being able
> to turn it off for performance code is why D is better than other languages
> offering bounds checks.

My experience showed that a good implementation in most cases does not slow down too much, so I often left all checks (array bounds, overflow, NIL pointer) on, except for well tested library functions.

"H. Ellenberger" <ele1@gmx.ch> wrote in message news:3C49E692.C9DE8997@gmx.ch...
> Walter wrote:
> > I've been working on implementing it. After turning it on and
recompiling
> > the library and test code, it tripped and found 3 bugs in the regexp implementation - code that I have a nice test suite for that was
passing.
> > Just goes to show, array bounds checking really is valuable!
> No surprise for people with experience in Topspeed Modula-2 which had this RT check many years ago.
> > And being able
> > to turn it off for performance code is why D is better than other
languages
> > offering bounds checks.
> My experience showed that a good implementation in most cases does not
slow
> down too much, so I often left all checks (array bounds, overflow, NIL
pointer)
> on, except for well tested library functions.

I figure by making it optional,  any objections to it should be addressed.

Walter wrote:

> I've been working on implementing it. After turning it on and recompiling
> the library and test code, it tripped and found 3 bugs in the regexp
> implementation - code that I have a nice test suite for that was passing.

And naturally you immediately added code to the test suite
that would have caught those bugs if the bounds check hadn't,
right? Belt and suspenders! Belt and suspenders!

Yes, the first time I started using a range-checked array
class, I was surprised at how many catches it made.

-R

"H. Ellenberger" <ele1@gmx.ch> ha scritto nel messaggio news:3C49E692.C9DE8997@gmx.ch...
> Walter wrote:
>
> > I've been working on implementing it. After turning it on and
recompiling
> > the library and test code, it tripped and found 3 bugs in the regexp implementation - code that I have a nice test suite for that was
passing.
> >
> > Just goes to show, array bounds checking really is valuable!
>
> No surprise for people with experience in Topspeed Modula-2 which had this RT check many years ago.

Or in Turbo Pascal, which had this optional RT check in the 80s.

Bouinds checking will eventually be seen as essential for both array and pointer operations.

A secondary bounded pointer type should be defined for that purpose.  It should be a composite type, and it should be targeted so that it is implemented in hardware, and throws an error when an access is attempted outside the bouinded range.

Walter <walter@digitalmars.com> wrote in message news:a2d4kq$1tdi$1@digitaldaemon.com...
>
> "H. Ellenberger" <ele1@gmx.ch> wrote in message news:3C49E692.C9DE8997@gmx.ch...
> > Walter wrote:
> > > I've been working on implementing it. After turning it on and
> recompiling
> > > the library and test code, it tripped and found 3 bugs in the regexp implementation - code that I have a nice test suite for that was
> passing.
> > > Just goes to show, array bounds checking really is valuable!
> > No surprise for people with experience in Topspeed Modula-2 which had this RT check many years ago.
> > > And being able
> > > to turn it off for performance code is why D is better than other
> languages
> > > offering bounds checks.
> > My experience showed that a good implementation in most cases does not
> slow
> > down too much, so I often left all checks (array bounds, overflow, NIL
> pointer)
> > on, except for well tested library functions.
>
> I figure by making it optional,  any objections to it should be addressed.
>
>
>

"D" <s_nudds@hotmail.com> wrote in message news:a3ll98$svr$1@digitaldaemon.com...
> Bouinds checking will eventually be seen as essential for both array and pointer operations.
>
> A secondary bounded pointer type should be defined for that purpose.  It should be a composite type, and it should be targeted so that it is implemented in hardware, and throws an error when an access is attempted outside the bouinded range.

"Bounded pointer" - i.e. a pointer that knows size of data it points to - is a D dynamic array:

    int[] a = new int[5];
    ...
    b = a[10];    // throws ArrayBoundsError

"D" <s_nudds@hotmail.com> wrote in message news:a3ll98$svr$1@digitaldaemon.com...
> Bouinds checking will eventually be seen as essential for both array and pointer operations.
>
> A secondary bounded pointer type should be defined for that purpose.  It should be a composite type, and it should be targeted so that it is implemented in hardware, and throws an error when an access is attempted outside the bouinded range.

Already in D! Well, a software version anyway.

Example: convert a pointer p into a "bounded pointer" bp:

char *p;
char[] bp = p[0..len];

Great.  I take it that all pointer increments and assignments are checked against the upper and lower bounds of the array, and an exception is thrown if the range is violated?

Walter <walter@digitalmars.com> wrote in message news:a3lp86$v31$1@digitaldaemon.com...
>
> "D" <s_nudds@hotmail.com> wrote in message news:a3ll98$svr$1@digitaldaemon.com...
> > Bouinds checking will eventually be seen as essential for both array and pointer operations.
> >
> > A secondary bounded pointer type should be defined for that purpose.  It should be a composite type, and it should be targeted so that it is implemented in hardware, and throws an error when an access is attempted outside the bouinded range.
>
> Already in D! Well, a software version anyway.
>
> Example: convert a pointer p into a "bounded pointer" bp:
>
> char *p;
> char[] bp = p[0..len];
>
>
>

"D" <s_nudds@hotmail.com> wrote in message news:a3ni7d$29f5$1@digitaldaemon.com...
> Great.  I take it that all pointer increments and assignments are checked against the upper and lower bounds of the array, and an exception is
thrown
> if the range is violated?

Not exactly. You don't increment dynamic arrays, but you do increment the index.

> Walter <walter@digitalmars.com> wrote in message news:a3lp86$v31$1@digitaldaemon.com...
> >
> > "D" <s_nudds@hotmail.com> wrote in message news:a3ll98$svr$1@digitaldaemon.com...
> > > Bouinds checking will eventually be seen as essential for both array
and
> > > pointer operations.
> > >
> > > A secondary bounded pointer type should be defined for that purpose.
It
> > > should be a composite type, and it should be targeted so that it is implemented in hardware, and throws an error when an access is
attempted
> > > outside the bouinded range.
> >
> > Already in D! Well, a software version anyway.
> >
> > Example: convert a pointer p into a "bounded pointer" bp:
> >
> > char *p;
> > char[] bp = p[0..len];
> >
> >
> >
>
>