www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Proposal - Check for null reference in debug build

reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
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.
Oct 20 2005
next sibling parent "Ameer Armaly" <ameer_armaly hotmail.com> writes:
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.
Oct 20 2005
prev sibling next sibling parent reply "Ben Hinkle" <bhinkle mathworks.com> writes:
 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?
Oct 20 2005
next sibling parent reply =?ISO-8859-1?Q?Jari-Matti_M=E4kel=E4?= <jmjmak invalid_utu.fi> writes:
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.
Oct 20 2005
next sibling parent Sean Kelly <sean f4.ca> writes:
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
Oct 20 2005
prev sibling parent "Ben Hinkle" <ben.hinkle gmail.com> writes:
"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.
Oct 20 2005
prev sibling parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"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?
Oct 20 2005
next sibling parent reply "Ben Hinkle" <ben.hinkle gmail.com> writes:
"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.
Oct 20 2005
next sibling parent reply =?ISO-8859-1?Q?Jari-Matti_M=E4kel=E4?= <jmjmak invalid_utu.fi> writes:
Ben Hinkle wrote:

 "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. 
 
 


I'm sorry, but this sounds a bit funny: "My OS supports segfaults". OTOH 
does the D specification say that all D implementations should generate 
code that supports segfaults. I mean if you use an old OS like Windows 
9x where memory manager only has a part-time job, the OS may not halt on 
every segfault.
Oct 20 2005
parent reply "Walter Bright" <newshound digitalmars.com> writes:
"Jari-Matti Mäkelä" <jmjmak invalid_utu.fi> wrote in message
news:dj98ii$bql$1 digitaldaemon.com...

 Ben Hinkle wrote:

 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.


 I'm sorry, but this sounds a bit funny: "My OS supports segfaults".


It's not quite true, seg faults are generated by the hardware, not the OS. I
do not know of any 32 bit system that doesn't operated in 'protected mode'
where seg faults happen in hardware, and is supported by the OS.

I agree with you that your proposal would be very useful for a real mode
operating system like DOS where there are no hardware seg faults or OS
support for them, but DOS is dead and 16 bit systems are not supported by D.


 OTOH
 does the D specification say that all D implementations should generate
 code that supports segfaults. I mean if you use an old OS like Windows
 9x where memory manager only has a part-time job, the OS may not halt on
 every segfault.


If you're running a 32 bit app under Win9x, you *will* get seg faults if you
dereference NULL, 100% of the time.
Oct 25 2005
next sibling parent reply =?ISO-8859-1?Q?Jari-Matti_M=E4kel=E4?= <jmjmak invalid_utu.fi> writes:
Walter Bright wrote:

OTOH
does the D specification say that all D implementations should generate
code that supports segfaults. I mean if you use an old OS like Windows
9x where memory manager only has a part-time job, the OS may not halt on
every segfault.


 
 
 If you're running a 32 bit app under Win9x, you *will* get seg faults if you
 dereference NULL, 100% of the time.
 
 


Ok, Win9x does support segfaults in a way. Still I don't find that 
information very helpful since it's so easy to hang up the whole system 
by doing some tiny errors. Several years ago I had to stop using Windows 
98 since it didn't always tell me (at least immediately) I was running 
some buggy code (illegal memory pointers). Linux does a lot better job 
in memory handling.
Oct 25 2005
parent "Walter Bright" <newshound digitalmars.com> writes:
"Jari-Matti Mäkelä" <jmjmak invalid_utu.fi> wrote in message
news:djm2p0$smq$1 digitaldaemon.com...

 Ok, Win9x does support segfaults in a way. Still I don't find that
 information very helpful since it's so easy to hang up the whole system
 by doing some tiny errors. Several years ago I had to stop using Windows
 98 since it didn't always tell me (at least immediately) I was running
 some buggy code (illegal memory pointers). Linux does a lot better job
 in memory handling.


The problem with Win9x isn't the seg fault detection. The problem is that
Win9x doesn't reclaim resources that were being used by a program that
exited via a seg fault, so Win9x often became unstable or wedged after a seg
fault. It needed to be rebooted upon a seg fault.

This misfeature made Win9x unsuitable for development. At the time, I used
WinNT for development which didn't have that problem, and ported to Win9x
only after it was completely debugged on NT.
Oct 28 2005
prev sibling parent BCS <BCS_member pathlink.com> writes:
In article <djlu53$agr$6 digitaldaemon.com>, Walter Bright says...

I agree with you that your proposal would be very useful for a real mode
operating system like DOS where there are no hardware seg faults or OS
support for them, but DOS is dead and 16 bit systems are not supported by D.


If you're running a 32 bit app under Win9x, you *will* get seg faults if you
dereference NULL, 100% of the time.


I think the point isn't to detect segfalts but to eliminate the need to use a
debugger to find the code that generated them. Alternately the program could
catch segfalts with it's own interrupt handler and print out a line number or
such.
Oct 25 2005
prev sibling parent "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Ben Hinkle" <ben.hinkle gmail.com> wrote in message 
news:dj966n$9km$1 digitaldaemon.com...

 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.


Depends on how much / where the memory is allocated.  If it happens to be on 
a page boundary, it might cause a segfault.

But this isn't really a counterargument for adding the feature I proposed.
Oct 20 2005
prev sibling parent "Walter Bright" <newshound digitalmars.com> writes:
"Jarrett Billingsley" <kb3ctd2 yahoo.com> wrote in message
news:dj95ji$964$1 digitaldaemon.com...

 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?


The debugger normally will not find array overruns, because they normally
won't cause a seg fault. They'll just cause data corruption, which may or
may not eventually result in erratic behavior.
Oct 25 2005
prev sibling next sibling parent reply =?ISO-8859-1?Q?Jari-Matti_M=E4kel=E4?= <jmjmak invalid_utu.fi> writes:
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?
Oct 20 2005
parent reply "Unknown W. Brackets" <unknown simplemachines.org> writes:
I think making it under -debug, which is only for debug {} sections, 
would be a mistake.

-[Unknown]



 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?
Oct 22 2005
parent =?ISO-8859-1?Q?Jari-Matti_M=E4kel=E4?= <jmjmak invalid_utu.fi> writes:
Unknown W. Brackets wrote:

 I think making it under -debug, which is only for debug {} sections, 
 would be a mistake.


Probably yes. IMO it should be turned on by default. Only -release and 
optimized versions should turn it off.
Oct 23 2005
prev sibling next sibling parent clayasaurus <clayasaurus gmail.com> writes:
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.
Oct 20 2005
prev sibling next sibling parent llothar <llothar_member pathlink.com> writes:
In article <dj8r60$30s1$1 digitaldaemon.com>, Jarrett Billingsley says...


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.


Yes would be nice if we a switch. But with todays superpipelined CPU's it's
amazing too see that the condition is almost completely eliminated, means there
is no (or maybe a simple one/two clock cycle) additional overhead. I'm still
using SmallEiffel and there this technique is the default. I even deliever my
final exe's with this options and some more buildin. And don't have any speed
problems, even when some parts are heavy CPU intensive


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. 


Yes, D is so bad in offering even simple debugging hints that i find it still
not worth using now, and surely wouldn't recommend it for serious developing.
Instead adding one feature after the other Walter should focus on development
support, not language features at the moment. By the way, when do we get
complete tracebacks of the stack after a pre/postcondition is violated, together
with writing this to a file (and send back to the developer) so we can get the
information even if it is executed on a customers computer ?
Oct 22 2005
prev sibling next sibling parent reply "Walter Bright" <newshound digitalmars.com> writes:
"Jarrett Billingsley" <kb3ctd2 yahoo.com> wrote in message
news:dj8r60$30s1$1 digitaldaemon.com...

 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();


But the hardware already does this for you.


 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.


All you need to do is compile with debug on (-g) and run the program under
the debugger. When the segfault happens, the debugger will put you right on
the line that failed.
Oct 25 2005
next sibling parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Walter Bright" <newshound digitalmars.com> wrote in message 
news:djlu52$agr$4 digitaldaemon.com...

 But the hardware already does this for you.


...


 All you need to do is compile with debug on (-g) and run the program under
 the debugger. When the segfault happens, the debugger will put you right 
 on
 the line that failed.


Which could be entirely bypassed if this check were performed automatically 
by the program.  That, and until there is some kind of integrated dev env 
for D, using a debugger will always be a chore.  That is, unless you really 
like starting up a separate program, set up the debugger in that so it 
breaks on acccess violations, running your program through that, and hoping 
the line mappings are correct and that the debugger can find the source 
files without being told.

I would not imagine that this would be a very difficult feature to 
implement, and as far as I can tell, there is no good reason not to.  D's 
philosophy is to make things easier, is it not?  That, and wouldn't this 
feature be a pretty nice selling point?  "No more vague memory access 
violations"?  I just can't believe that you don't hate segfaults with a 
passion.
Oct 25 2005
next sibling parent reply "Kris" <fu bar.com> writes:
Jarrett,

Suppose the OS could catch the segfault, fire up a 'dev environment' for 
you, and identify the offending line of code ~ would that suffice?

- Kris


"Jarrett Billingsley" <kb3ctd2 yahoo.com> wrote in message 
news:djmq25$26mu$1 digitaldaemon.com...

 "Walter Bright" <newshound digitalmars.com> wrote in message 
 news:djlu52$agr$4 digitaldaemon.com...

 But the hardware already does this for you.


 ...


 All you need to do is compile with debug on (-g) and run the program 
 under
 the debugger. When the segfault happens, the debugger will put you right 
 on
 the line that failed.


 Which could be entirely bypassed if this check were performed 
 automatically by the program.  That, and until there is some kind of 
 integrated dev env for D, using a debugger will always be a chore.  That 
 is, unless you really like starting up a separate program, set up the 
 debugger in that so it breaks on acccess violations, running your program 
 through that, and hoping the line mappings are correct and that the 
 debugger can find the source files without being told.

 I would not imagine that this would be a very difficult feature to 
 implement, and as far as I can tell, there is no good reason not to.  D's 
 philosophy is to make things easier, is it not?  That, and wouldn't this 
 feature be a pretty nice selling point?  "No more vague memory access 
 violations"?  I just can't believe that you don't hate segfaults with a 
 passion.
Oct 25 2005
parent reply Dan <Dan_member pathlink.com> writes:
Jarret, I would love to see that.
Oct 25 2005
parent xs0 <xs0 xs0.com> writes:
Dan wrote:

 Jarret, I would love to see that.
 
 


Dan, if you don't mind - please quote what you're replying to.. Many 
people don't read news in a threaded view (me included, obviously), so 
if you just do it like above, we have no idea what you're talking about ;)


xs0
Oct 26 2005
prev sibling parent "Walter Bright" <newshound digitalmars.com> writes:
"Jarrett Billingsley" <kb3ctd2 yahoo.com> wrote in message
news:djmq25$26mu$1 digitaldaemon.com...

 "Walter Bright" <newshound digitalmars.com> wrote in message
 news:djlu52$agr$4 digitaldaemon.com...

 But the hardware already does this for you.
 All you need to do is compile with debug on (-g) and run the program




under

 the debugger. When the segfault happens, the debugger will put you right
 on
 the line that failed.


 Which could be entirely bypassed if this check were performed


automatically

 by the program.  That, and until there is some kind of integrated dev env
 for D, using a debugger will always be a chore.  That is, unless you


really

 like starting up a separate program, set up the debugger in that so it
 breaks on acccess violations, running your program through that, and


hoping

 the line mappings are correct and that the debugger can find the source
 files without being told.


I do it all the time, it isn't a chore. Instead of:

C> foo args...

I type in:

C> windbg foo.exe args...

and click on run in the debugger. When it segfaults, I get a nice call
stack, with source or asm display for each entry in the call stack. The
debugger doesn't need to be set up for breaking on access violations, it
can't *not* do it. Unless you've moved the source files or the executable,
it finds them.


 I would not imagine that this would be a very difficult feature to
 implement, and as far as I can tell, there is no good reason not to.  D's
 philosophy is to make things easier, is it not?  That, and wouldn't this
 feature be a pretty nice selling point?  "No more vague memory access
 violations"?  I just can't believe that you don't hate segfaults with a
 passion.


My views on seg faults were shaped from the bad old DOS days when you didn't
get seg faults, you discovered something was wrong with your program when
your hard disk was scrambled and you had to restore your entire hard disk. I
*love* seg faults because it pinpoints a bug in your program usually very
close to where it actually is. I don't have to reboot anymore or constantly
be restoring my hard disk. Seg faults are the biggest advance in programmer
productivity since compilers.
Oct 28 2005
prev sibling parent reply Bruno Medeiros <daiphoenixNO SPAMlycos.com> writes:
Walter Bright wrote:

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.


 
 
 All you need to do is compile with debug on (-g) and run the program under
 the debugger. When the segfault happens, the debugger will put you right on
 the line that failed.
 


Still, having the compiler throw a NullPointerException on a segfault 
(or AccessViolation), and then dump a stack trace (à la Java) would be 
nice, altough not prioritary I guess.


-- 
Bruno Medeiros - CS/E student
"Certain aspects of D are a pathway to many abilities some consider to 
be... unnatural."
Oct 26 2005
parent "Walter Bright" <newshound digitalmars.com> writes:
"Bruno Medeiros" <daiphoenixNO SPAMlycos.com> wrote in message
news:djnh7c$16h2$1 digitaldaemon.com...

 Still, having the compiler throw a NullPointerException on a segfault
 (or AccessViolation), and then dump a stack trace (à la Java) would be
 nice, altough not prioritary I guess.


I agree, it would be nice. But it isn't trivial to implement, the capability
is already available via the debugger, and other missing things have much
higher priority (like shared library support, better symbolic debug info,
etc.).
Oct 28 2005
prev sibling parent reply =?iso-8859-1?q?Knud_S=F8rensen?= <12tkvvb02 sneakemail.com> writes:
On Thu, 20 Oct 2005 15:29:05 -0400, 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];
 


I like your idea why don't you add it to the unofficial wish list ?

http://all-technology.com/eigenpolls/dwishlist/
Oct 27 2005
next sibling parent "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Knud Sørensen" <12tkvvb02 sneakemail.com> wrote in message 
news:pan.2005.10.27.11.56.43.124177 sneakemail.com...

 I like your idea why don't you add it to the unofficial wish list ?


Done.  Though who knows if it'll make much of a difference..
Oct 27 2005
prev sibling parent reply Bruno Medeiros <daiphoenixNO SPAMlycos.com> writes:
Knud Sørensen wrote:

 I like your idea why don't you add it to the unofficial wish list ?
 
 http://all-technology.com/eigenpolls/dwishlist/


Return-type overloading as the number one feature?? That is just plain nuts!

-- 
Bruno Medeiros - CS/E student
"Certain aspects of D are a pathway to many abilities some consider to 
be... unnatural."
Oct 27 2005
parent reply Derek Parnell <derek psych.ward> writes:
On Thu, 27 Oct 2005 21:50:46 +0100, Bruno Medeiros wrote:


 Knud Sørensen wrote:

 I like your idea why don't you add it to the unofficial wish list ?
 
 http://all-technology.com/eigenpolls/dwishlist/


 
 Return-type overloading as the number one feature?? That is just plain nuts!


Yes, I often thought that the scoring algorithm for this poll is wrong. It
seems to only take into consideration the relative ranking of each item
within each submitter's list, but it should also consider the number of
submitters for each item as a factor.


shots to the top of the list. Conversely, if you wish to reduce the ranking
of an item it is better to include it in your personal list at the bottom
than to not vote for it at all.

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
28/10/2005 6:41:43 PM
Oct 28 2005
next sibling parent reply Don Clugston <dac nospam.com.au> writes:
Derek Parnell wrote:

 On Thu, 27 Oct 2005 21:50:46 +0100, Bruno Medeiros wrote:
 
 

Knud Sørensen wrote:


I like your idea why don't you add it to the unofficial wish list ?

http://all-technology.com/eigenpolls/dwishlist/


Return-type overloading as the number one feature?? That is just plain nuts!


 
 
 Yes, I often thought that the scoring algorithm for this poll is wrong. It
 seems to only take into consideration the relative ranking of each item
 within each submitter's list, but it should also consider the number of
 submitters for each item as a factor.
 

 shots to the top of the list. Conversely, if you wish to reduce the ranking
 of an item it is better to include it in your personal list at the bottom
 than to not vote for it at all.


It's a ridiculous algorithm. At least you'd get relatively sensible 
results if you ordered by number of votes.
Oct 28 2005
parent Georg Wrede <georg.wrede nospam.org> writes:
Don Clugston wrote:

 Derek Parnell wrote:
 

 On Thu, 27 Oct 2005 21:50:46 +0100, Bruno Medeiros wrote:



 Knud Sørensen wrote:


 I like your idea why don't you add it to the unofficial wish list ?

 http://all-technology.com/eigenpolls/dwishlist/



 Return-type overloading as the number one feature?? That is just 
 plain nuts!




 Yes, I often thought that the scoring algorithm for this poll is 
 wrong. It
 seems to only take into consideration the relative ranking of each item
 within each submitter's list, but it should also consider the number of
 submitters for each item as a factor.


 shots to the top of the list. Conversely, if you wish to reduce the 
 ranking
 of an item it is better to include it in your personal list at the bottom
 than to not vote for it at all.


 
 
 It's a ridiculous algorithm. At least you'd get relatively sensible 
 results if you ordered by number of votes.


Right. And if one wants to give much priority to his pets, then include 
every other suggestion too, below the pet.

So, everybody ends up having all entries in their list, which only 
results in most other than the top/bottom few being in more or less an 
arbitrary order.

Which of course invalidates the entire purpose of the algorithm.

Not to mention, such lists tend to become lists of nice features, with 
no regard to the relative effort or priority of each. A nice sounding 
cool feature gets higher than an essential feature that is not possible 
to explain to newbies or passers-by with only a half sentence.
Oct 29 2005
prev sibling parent Bruno Medeiros <daiphoenixNO SPAMlycos.com> writes:
Derek Parnell wrote:

 On Thu, 27 Oct 2005 21:50:46 +0100, Bruno Medeiros wrote:
 
 

Knud Sørensen wrote:


I like your idea why don't you add it to the unofficial wish list ?

http://all-technology.com/eigenpolls/dwishlist/


Return-type overloading as the number one feature?? That is just plain nuts!


 
 
 Yes, I often thought that the scoring algorithm for this poll is wrong.


Indeed. I think a feature/change feedback system would be nice (even if 
a simple one), but I don't think a poll system works at all for that 
purpose. One should have a voting/ranking for each individual 
feature/change, not a ranking amongst them. And it would also need the 
following:
* User Autentication (to avoid duplicate votes)
* Allow negative voting. (i.e. deslike)

-- 
Bruno Medeiros - CS/E student
"Certain aspects of D are a pathway to many abilities some consider to 
be... unnatural."
Oct 29 2005