"Pavel Minayev" <evilone@omen.ru> wrote in message news:ab45q3$39j$1@digitaldaemon.com...
> "Walter" <walter@digitalmars.com> wrote in message news:ab426r$310j$3@digitaldaemon.com...
> > Null pointer dereferences should GP fault, not hang. Since the hardware
> does
> > the check for free, there's no profit to adding it into the language. Remember, you can write exception handlers to catch GP fault exceptions.
> But still... not every hardware does,

Correct, the 16 bit PC did not, which made the PC a terrible platform for code development. That's why I, as much as possible, developed 16 bit code using OS/2 1.1 and using 286 DOS extenders. When all was working, then I built a real mode version.

> and even then, I'd like to see
> the message explaining what REALLY happened, and not just another cryptic
> GP error "info".

All I need is having it pop up in the debugger with the offending code position highlighted.

"Walter" <walter@digitalmars.com> wrote in message news:ab5mau$1io7$1@digitaldaemon.com...

> All I need is having it pop up in the debugger with the offending code position highlighted.

We are yet to see a debugger (probably integrated into the IDE) for D. This is something that will probably not happen in near future. On other hand, inserting a simple assert(obj) check is a matter of minutes, and would greatly simplify things to us now, and to those guys - like me - who still prefer good old command-line.

"Pavel Minayev" <evilone@omen.ru> wrote in message news:ab53vt$thl$1@digitaldaemon.com...
> "Jonathan Andrew" <jon@ece.arizona.edu> wrote in message news:3CD601AB.7030707@ece.arizona.edu...
>
> > That would be a fantastic idea, but does D compile the source code line
> > information in with the program? It would be nice if that were an option
> > during compile time, and if you wanted that information (along with the
> > added bloat) you would get nice error messages, perfect for debugging,
> > then for memory-constrained apps you could leave that info out? Has this
> >   been discussed yet?
>
> Of course this should only happen in debug builds!
>
> As for the line info... well, assertions do store it (try assert(false)),
> so why not other exceptions that are inserted by the compiler?


As long as you don't care if it is precisely accurate.  With heavy optimizaton, it sometimes isn't at all obvious to which source line a particular instruction belongs (for example, it might be more than one) and it is certainly no longer the case that a contiguous group of instructions belongs to a single source line.  This makes keeping source line number much more costly to implement.

--
 - Stephen Fuld
   e-mail address disguised to prevent spam

"Sean L. Palmer" <spalmer@iname.com> wrote in message news:ab5apj$16r5$1@digitaldaemon.com...
> I disagree.  For one, some architectures (68K, Playstation 1, 6502) cannot generate hardware GP faults so such errors will go undetected.
>
> I think it would be a valuable debugging tool to throw on dereference of null object references.  Obviously only in debug builds, or perhaps only
in
> "extra debug" builds...?

If nil is, in fact, equal to zero, then we are talking about typically one extra instruction, and on modern CPUs that instruction can usually be done in parallel with the start of whatever is next, so the cost is pretty minimal.  I'm not sure it shouldn't be the default to keep those checks in, but there is certainly no need for "extra debug" flags.

--
 - Stephen Fuld
   e-mail address disguised to prevent spam

>>>
>>Of course this should only happen in debug builds!
>>
>>As for the line info... well, assertions do store it (try assert(false)),
>>so why not other exceptions that are inserted by the compiler?
>>
> 
> 
> As long as you don't care if it is precisely accurate.  With heavy
> optimizaton, it sometimes isn't at all obvious to which source line a
> particular instruction belongs (for example, it might be more than one) and
> it is certainly no longer the case that a contiguous group of instructions
> belongs to a single source line.  This makes keeping source line number much
> more costly to implement.
> 
> --
>  - Stephen Fuld
>    e-mail address disguised to prevent spam
> 


In debug builds, heavy optimization isn't as much a priority as functional code (unless you are a real speed freak) so IMHO, I think this concern shouldn't outweigh the benefits of having that kind of
information available.

"Stephen Fuld" <s.fuld.pleaseremove@att.net> wrote in message news:ab6g1p$2gau$1@digitaldaemon.com...

> As long as you don't care if it is precisely accurate.  With heavy optimizaton, it sometimes isn't at all obvious to which source line a particular instruction belongs (for example, it might be more than one)
and
> it is certainly no longer the case that a contiguous group of instructions belongs to a single source line.  This makes keeping source line number
much
> more costly to implement.

When optimizations are on, all assert() are removed. What I proposed is that compiler silently inserts an assert (with properly modified error message) before each deferencing. Since asserts are already implemented, no additional work is needed to make line numbers work.

"Stephen Fuld" <s.fuld.pleaseremove@att.net> wrote in message news:ab6g1r$2gau$2@digitaldaemon.com...

> If nil is, in fact, equal to zero, then we are talking about typically one extra instruction, and on modern CPUs that instruction can usually be done in parallel with the start of whatever is next, so the cost is pretty

Something more useful could be done in parallel instead of null-check.

> minimal.  I'm not sure it shouldn't be the default to keep those checks
in,
> but there is certainly no need for "extra debug" flags.

Yep, just "debug" is fine. =)
Personally, I do not want those checks in release version - I'd rather have
it running at full speed. The best approach, IMO, is to follow the way
array bounds checking is done - default ON in debug version, default OFF
in release version, and an option to change it if necessary...

"Pavel Minayev" <evilone@omen.ru> wrote in message news:ab7ilk$k17$1@digitaldaemon.com...
> "Stephen Fuld" <s.fuld.pleaseremove@att.net> wrote in message news:ab6g1r$2gau$2@digitaldaemon.com...
>
> > If nil is, in fact, equal to zero, then we are talking about typically
one
> > extra instruction, and on modern CPUs that instruction can usually be
done
> > in parallel with the start of whatever is next, so the cost is pretty
>
> Something more useful could be done in parallel instead of null-check.
>
> > minimal.  I'm not sure it shouldn't be the default to keep those checks
> in,
> > but there is certainly no need for "extra debug" flags.
>
> Yep, just "debug" is fine. =)
> Personally, I do not want those checks in release version - I'd rather
have
> it running at full speed. The best approach, IMO, is to follow the way array bounds checking is done - default ON in debug version, default OFF in release version, and an option to change it if necessary...

I don't have a problem with that.

--
 - Stephen Fuld
   e-mail address disguised to prevent spam

In article <ab426r$310j$3@digitaldaemon.com>, Walter says...
>
>Null pointer dereferences should GP fault, not hang. Since the hardware does the check for free, there's no profit to adding it into the language. Remember, you can write exception handlers to catch GP fault exceptions.

It shouldn't hang but it actually does. Is it a bug?

"MicroWizard" <MicroWizard_member@pathlink.com> wrote in message news:ab93ob$21qo$1@digitaldaemon.com...
> In article <ab426r$310j$3@digitaldaemon.com>, Walter says...
> >
> >Null pointer dereferences should GP fault, not hang. Since the hardware
does
> >the check for free, there's no profit to adding it into the language. Remember, you can write exception handlers to catch GP fault exceptions.
>
> It shouldn't hang but it actually does. Is it a bug?
>
>


Is the pointer really null? Often dereferencing a pointer that is not null, but just contains garbage can cause a hang.


--
Stijn
OddesE_XYZ@hotmail.com
http://OddesE.cjb.net
_________________________________________________
Remove _XYZ from my address when replying by mail