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

Clear and short code.
After few second the "standard" GPF appears almost always.

Tamas

----------------------
import c.stdio;

class xRecord{
int b;
this() {b=3;}
}

void main(char[][] args)
{
xRecord xr2;
//      xr2=new xRecord(); //********************************
if(xr2==null)
{
printf("xr2 is null\n");
}
xr2.set(10); // hangs up if xr2 equals to null
}

"OddesE" <OddesE_XYZ@hotmail.com> wrote in message news:ab4729$4qa$1@digitaldaemon.com...
> Yep. "Null pointer dereferenced at line #25:
mynullpointer->DoSomething();"
> would be a thousand times more valuable than "MYDAPP.EXE caused a general protection fault at address 34EF:4FEC: read of address 0000:0000"...

That's basically what happens when you run the app under the debugger. You can also see the call stack, etc.

Pavel Minayev wrote:
> > 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, and even then, I'd like to see
> the message explaining what REALLY happened, and not just another cryptic
> GP error "info".
There are lots of hardware platforms (even x86) out there where a NULL
pointer is a valid pointer. When Walter want
s to implement it, it should be optional ... or you should be able to
turn it on/off by a pragma or something like that.

Best regards,
Mark Junker

"Alexander Lahmann" <info@elco-pro.de> wrote in message news:3CDEC72D.D879A4AB@elco-pro.de...

> There are lots of hardware platforms (even x86) out there where a NULL
> pointer is a valid pointer.

However, I'm not aware of any platform where null is a legal object
reference - and I was talking only about objects. Of course, traditional
pointers are left for low-level tasks, and shouldn't have any checks
on them.

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

Yes.

> It would be nice if that were an option
> during compile time,

-g

> 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?

If you run a D compiled program under a debugger, and it triggers a GP fault, the debugger will pop up with the cursor on the source line that failed.

"Pavel Minayev" <evilone@omen.ru> wrote in message news:ab5rsa$1oed$1@digitaldaemon.com...
> "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.

D works with common debuggers, like Windbg.exe.

"Alexander Lahmann" <info@elco-pro.de> wrote in message news:3CDEC72D.D879A4AB@elco-pro.de...
> There are lots of hardware platforms (even x86) out there where a NULL
> pointer is a valid pointer. When Walter want
> s to implement it, it should be optional ... or you should be able to
> turn it on/off by a pragma or something like that.

Just checking for null pointers on the x86 was rarely good enough. Many invalid pointers have random values which would scramble DOS's data areas.

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

> Just checking for null pointers on the x86 was rarely good enough. Many invalid pointers have random values which would scramble DOS's data areas.

Oh, I see now. All object references on stack are undefined, anyhow, so null-check won't help much...