We already have array bounds checking in the debug build, accomplished through a sort of implicit assert, such that

int x = array[index];

Becomes

assert(index >= 0 && index < array.length); int x = array[index];

This is to prevent (mostly) the irritating off-by-one errors so common in array handling but which cause a vague memory access violation in nonprotected languages such as C++.  This is a very helpful debugging feature.

I think that a logical extension of this would be to check for null references in debug builds as well.  How many times has trying to call a method of a null reference bitten you?  I propose that this:

obj.doSomething();

Would be implicitly compiled as

assert(obj !is null); obj.doSomething();

This would severly cut down on the amount of "find the segfault" scavenger hunts that are the bane of any programmer's existence.

Since this might severely impact performance, it might even be implemented as a separate compiler switch which could only be used in conjunction with the -debug switch.  Then you could turn it on if you get a segfault and see if it's a null reference that's causing it.

I'm really tired of stepping through code to find segfaults, and I think this would almost entirely eliminate segfaults in D except when dealing with pointers.

Interesting.  I see how it would cut down on segfaults, and I do agree that
the find the segfault game is rather borring.
"Jarrett Billingsley" <kb3ctd2@yahoo.com> wrote in message
news:dj8r60$30s1$1@digitaldaemon.com...
> We already have array bounds checking in the debug build, accomplished through a sort of implicit assert, such that
>
> int x = array[index];
>
> Becomes
>
> assert(index >= 0 && index < array.length); int x = array[index];
>
> This is to prevent (mostly) the irritating off-by-one errors so common in array handling but which cause a vague memory access violation in nonprotected languages such as C++.  This is a very helpful debugging feature.
>
> I think that a logical extension of this would be to check for null references in debug builds as well.  How many times has trying to call a method of a null reference bitten you?  I propose that this:
>
> obj.doSomething();
>
> Would be implicitly compiled as
>
> assert(obj !is null); obj.doSomething();
>
> This would severly cut down on the amount of "find the segfault" scavenger hunts that are the bane of any programmer's existence.
>
> Since this might severely impact performance, it might even be implemented as a separate compiler switch which could only be used in conjunction with the -debug switch.  Then you could turn it on if you get a segfault and see if it's a null reference that's causing it.
>
> I'm really tired of stepping through code to find segfaults, and I think this would almost entirely eliminate segfaults in D except when dealing with pointers.
> 

> I'm really tired of stepping through code to find segfaults, and I think this would almost entirely eliminate segfaults in D except when dealing with pointers.


I'm able to get both Visual Studio and gdb to break at seg-v's. I'm pretty sure windbg also breaks. Is the reason for wanting an assert exception to get the file and line number without having to start a debugger?

Jarrett Billingsley wrote:
> We already have array bounds checking in the debug build, accomplished through a sort of implicit assert, such that
> 
> int x = array[index];
> 
> Becomes
> 
> assert(index >= 0 && index < array.length); int x = array[index];
> 
> This is to prevent (mostly) the irritating off-by-one errors so common in array handling but which cause a vague memory access violation in nonprotected languages such as C++.  This is a very helpful debugging feature.
> 
> I think that a logical extension of this would be to check for null references in debug builds as well.  How many times has trying to call a method of a null reference bitten you?  I propose that this:
> 
> obj.doSomething();
> 
> Would be implicitly compiled as
> 
> assert(obj !is null); obj.doSomething();
> 
> This would severly cut down on the amount of "find the segfault" scavenger hunts that are the bane of any programmer's existence.
> 
> Since this might severely impact performance, it might even be implemented as a separate compiler switch which could only be used in conjunction with the -debug switch.  Then you could turn it on if you get a segfault and see if it's a null reference that's causing it.
> 
> I'm really tired of stepping through code to find segfaults, and I think this would almost entirely eliminate segfaults in D except when dealing with pointers. 
> 
> 

This would definitely be useful. I've noticed that ~70% of my programming errors are weird segfaults caused by a few nulls in a wrong place.

It shouldn't cause too much trouble to include this functionality under the -debug flag. The only downside would be slightly decreased performance. I don't care - why should we care about the speed of debug-mode code in the first place? IMHO only asymptotic time complexity matters.

BTW. Has Walter any plans to finally implement the compile-time unit tests?

Ben Hinkle wrote:
>>I'm really tired of stepping through code to find segfaults, and I think this would almost entirely eliminate segfaults in D except when dealing with pointers.
> 
> 
> 
> I'm able to get both Visual Studio and gdb to break at seg-v's. I'm pretty sure windbg also breaks. Is the reason for wanting an assert exception to get the file and line number without having to start a debugger?
> 
> 
> 
Do we really have good debuggers for Linux? I think this feature would be both useful and newbie-friendly. Ok, gdb might be very good, but it's hard to use. Besides you need to apply a patch to use it. This is not a real problem, but someone has to create new patches for the future versions of gdb.

In article <dj919j$5e0$1@digitaldaemon.com>, =?ISO-8859-1?Q?Jari-Matti_M=E4kel=E4?= says...
>
>Do we really have good debuggers for Linux? I think this feature would be both useful and newbie-friendly. Ok, gdb might be very good, but it's hard to use. Besides you need to apply a patch to use it. This is not a real problem, but someone has to create new patches for the future versions of gdb.

Emacs integrated gdb debugging works pretty well IMO.  If you want an IDE front-end however, I always thought KDevelop looked pretty nice: http://www.kdevelop.org/


Sean

Jarrett Billingsley wrote:
> We already have array bounds checking in the debug build, accomplished through a sort of implicit assert, such that
> 
> int x = array[index];
> 
> Becomes
> 
> assert(index >= 0 && index < array.length); int x = array[index];
> 
> This is to prevent (mostly) the irritating off-by-one errors so common in array handling but which cause a vague memory access violation in nonprotected languages such as C++.  This is a very helpful debugging feature.
> 
> I think that a logical extension of this would be to check for null references in debug builds as well.  How many times has trying to call a method of a null reference bitten you?  I propose that this:
> 
> obj.doSomething();
> 
> Would be implicitly compiled as
> 
> assert(obj !is null); obj.doSomething();
> 
> This would severly cut down on the amount of "find the segfault" scavenger hunts that are the bane of any programmer's existence.
> 
> Since this might severely impact performance, it might even be implemented as a separate compiler switch which could only be used in conjunction with the -debug switch.  Then you could turn it on if you get a segfault and see if it's a null reference that's causing it.
> 
> I'm really tired of stepping through code to find segfaults, and I think this would almost entirely eliminate segfaults in D except when dealing with pointers. 
> 
> 


I think this is a good idea and should be on by default in debug mode, having a flag or something to turn it off if desired.

This will save time fiddling with gdb and will give newb's a better impression of the language in general. 'seg fault' with no line number doesn't give a nice impression, and if it can be avoided, then I say do it.

"Ben Hinkle" <bhinkle@mathworks.com> wrote in message news:dj8tdj$212$1@digitaldaemon.com...
> I'm able to get both Visual Studio and gdb to break at seg-v's. I'm pretty sure windbg also breaks. Is the reason for wanting an assert exception to get the file and line number without having to start a debugger?

Mostly, yes.  It's such a common mistake to try to access a null reference that it should be checked for by the debug build.

That, and we've already done away with the need to use the debugger to find segfaults caused by invalid array indices; why not take it the rest of the way?

"Jari-Matti Mäkelä" <jmjmak@invalid_utu.fi> wrote in message news:dj919j$5e0$1@digitaldaemon.com...
> Ben Hinkle wrote:
>>>I'm really tired of stepping through code to find segfaults, and I think this would almost entirely eliminate segfaults in D except when dealing with pointers.
>>
>> I'm able to get both Visual Studio and gdb to break at seg-v's. I'm pretty sure windbg also breaks. Is the reason for wanting an assert exception to get the file and line number without having to start a debugger?
>>
> Do we really have good debuggers for Linux? I think this feature would be both useful and newbie-friendly. Ok, gdb might be very good, but it's hard to use. Besides you need to apply a patch to use it. This is not a real problem, but someone has to create new patches for the future versions of gdb.

I use gdb without any patches. I know there's some patch to recognize some D-specific data types but I get along ok without it so I've never tried it. Certainly catching segv's doesn't need a patch.

"Jarrett Billingsley" <kb3ctd2@yahoo.com> wrote in message news:dj95ji$964$1@digitaldaemon.com...
> "Ben Hinkle" <bhinkle@mathworks.com> wrote in message news:dj8tdj$212$1@digitaldaemon.com...
>> I'm able to get both Visual Studio and gdb to break at seg-v's. I'm pretty sure windbg also breaks. Is the reason for wanting an assert exception to get the file and line number without having to start a debugger?
>
> Mostly, yes.  It's such a common mistake to try to access a null reference that it should be checked for by the debug build.
>
> That, and we've already done away with the need to use the debugger to find segfaults caused by invalid array indices; why not take it the rest of the way?

Array bounds errors are not caught by the OS. Code silently continues when you index one past an array but trying to access null generates an immediate segv. So adding code to check for array bounds errors is needed because there is no OS support for it.