www.digitalmars.com         C & C++   DMDScript  

D - DMD 0.68 bug: Assert on object references causing an exception.

reply Burton Radons <loth users.sourceforge.net> writes:
This code:

    void main ()
    {
        Object foo;
        assert (foo);
    }

Compiles but has an "Error: Access Violation" on execution.
Jul 27 2003
parent reply "Walter" <walter digitalmars.com> writes:
"Burton Radons" <loth users.sourceforge.net> wrote in message
news:bg0r8t$2jh7$1 digitaldaemon.com...
 This code:

     void main ()
     {
         Object foo;
         assert (foo);
     }

 Compiles but has an "Error: Access Violation" on execution.
Correct, since foo is null.
Jul 27 2003
parent reply Burton Radons <loth users.sourceforge.net> writes:
Walter wrote:

 "Burton Radons" <loth users.sourceforge.net> wrote in message
 news:bg0r8t$2jh7$1 digitaldaemon.com...
 
This code:

    void main ()
    {
        Object foo;
        assert (foo);
    }

Compiles but has an "Error: Access Violation" on execution.
Correct, since foo is null.
Not correct, man. Assert is not behaving here in the same way as if, for, while, or the trinary operator. This test is implicitly defined as being equivalent to "foo !== null" in the Expressions/Cast Expressions section, and the AssertExpression definition gives no indication that it alters casting semantics for its special case.
Jul 27 2003
parent reply "Walter" <walter digitalmars.com> writes:
"Burton Radons" <loth users.sourceforge.net> wrote in message
news:bg0vpb$2om0$1 digitaldaemon.com...
 Walter wrote:

 "Burton Radons" <loth users.sourceforge.net> wrote in message
 news:bg0r8t$2jh7$1 digitaldaemon.com...

This code:

    void main ()
    {
        Object foo;
        assert (foo);
    }

Compiles but has an "Error: Access Violation" on execution.
Correct, since foo is null.
Not correct, man. Assert is not behaving here in the same way as if, for, while, or the trinary operator. This test is implicitly defined as being equivalent to "foo !== null" in the Expressions/Cast Expressions section, and the AssertExpression definition gives no indication that it alters casting semantics for its special case.
So you argue it should give an AssertException rather than an access violation exception?
Jul 27 2003
next sibling parent reply Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:
Walter wrote:
 "Burton Radons" <loth users.sourceforge.net> wrote in message
 news:bg0vpb$2om0$1 digitaldaemon.com...
 
Walter wrote:


"Burton Radons" <loth users.sourceforge.net> wrote in message
news:bg0r8t$2jh7$1 digitaldaemon.com...


This code:

   void main ()
   {
       Object foo;
       assert (foo);
   }

Compiles but has an "Error: Access Violation" on execution.
Correct, since foo is null.
Not correct, man. Assert is not behaving here in the same way as if, for, while, or the trinary operator. This test is implicitly defined as being equivalent to "foo !== null" in the Expressions/Cast Expressions section, and the AssertExpression definition gives no indication that it alters casting semantics for its special case.
So you argue it should give an AssertException rather than an access violation exception?
That's certainly what I expected it to do when I read the code! Russ
Jul 27 2003
parent reply "Walter" <walter digitalmars.com> writes:
"Russ Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message
news:bg15ra$2ukf$1 digitaldaemon.com...
 So you argue it should give an AssertException rather than an access
 violation exception?
That's certainly what I expected it to do when I read the code!
I've had a similar long discussion with Matthew about things like this. The idea is that accessing a null pointer generates a hardware exception. The D runtime library turns the hardware exception into a D exception, accessible with a catch statement. If those exceptions are not caught in user code, they're caught by phobos/dmain2.d and the associated message is printed out, in this case, "Access Violation". Hardware exceptions are not program crashes any more than software exceptions are. The nice thing about hardware exceptions is you get them for 'free' - no code bloat, no runtime performance penalty. So why make an extra software test for a null pointer and generate an exception? Let the hardware do it for free.
Aug 09 2003
parent reply Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:
Walter wrote:
 "Russ Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message
 news:bg15ra$2ukf$1 digitaldaemon.com...
 
So you argue it should give an AssertException rather than an access
violation exception?
That's certainly what I expected it to do when I read the code!
I've had a similar long discussion with Matthew about things like this. The idea is that accessing a null pointer generates a hardware exception. The D runtime library turns the hardware exception into a D exception, accessible with a catch statement. If those exceptions are not caught in user code, they're caught by phobos/dmain2.d and the associated message is printed out, in this case, "Access Violation". Hardware exceptions are not program crashes any more than software exceptions are. The nice thing about hardware exceptions is you get them for 'free' - no code bloat, no runtime performance penalty. So why make an extra software test for a null pointer and generate an exception? Let the hardware do it for free.
In what way do you interpret the assert such that it would cause a hardware exception? The only way to cause a hardware exception is to dereference the null pointer (reference, sorry). Why would you do that in an assert?
Aug 10 2003
parent reply "Walter" <walter digitalmars.com> writes:
"Russ Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message
news:bh62vo$21bt$1 digitaldaemon.com...
 Walter wrote:
 "Russ Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message
 news:bg15ra$2ukf$1 digitaldaemon.com...
So you argue it should give an AssertException rather than an access
violation exception?
That's certainly what I expected it to do when I read the code!
I've had a similar long discussion with Matthew about things like this.
The
 idea is that accessing a null pointer generates a hardware exception.
The D
 runtime library turns the hardware exception into a D exception,
accessible
 with a catch statement. If those exceptions are not caught in user code,
 they're caught by phobos/dmain2.d and the associated message is printed
out,
 in this case, "Access Violation".

 Hardware exceptions are not program crashes any more than software
 exceptions are.

 The nice thing about hardware exceptions is you get them for 'free' - no
 code bloat, no runtime performance penalty. So why make an extra
software
 test for a null pointer and generate an exception? Let the hardware do
it
 for free.
In what way do you interpret the assert such that it would cause a hardware exception? The only way to cause a hardware exception is to dereference the null pointer (reference, sorry). Why would you do that in an assert?
An assert on an object reference calls the invariant for that object. If the reference is null, it'll gp fault.
Aug 16 2003
parent reply Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:
Walter wrote:
 "Russ Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message
 news:bh62vo$21bt$1 digitaldaemon.com...
 
In what way do you interpret the assert such that it would cause a
hardware exception?  The only way to cause a hardware exception is to
dereference the null pointer (reference, sorry).  Why would you do that
in an assert?
An assert on an object reference calls the invariant for that object. If the reference is null, it'll gp fault.
Ok, that sounds reasonable. But is there any reason why it shouldn't check against null first? We are in debug mode, so performance isn't (as much of) an issue.
Aug 21 2003
parent "Walter" <walter digitalmars.com> writes:
"Russ Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message
news:bi2ib7$3015$1 digitaldaemon.com...
 Walter wrote:
 "Russ Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message
 news:bh62vo$21bt$1 digitaldaemon.com...

In what way do you interpret the assert such that it would cause a
hardware exception?  The only way to cause a hardware exception is to
dereference the null pointer (reference, sorry).  Why would you do that
in an assert?
An assert on an object reference calls the invariant for that object. If
the
 reference is null, it'll gp fault.
Ok, that sounds reasonable. But is there any reason why it shouldn't check against null first? We are in debug mode, so performance isn't (as much of) an issue.
Why bother if the hardware does it for you?
Sep 09 2003
prev sibling parent Burton Radons <loth users.sourceforge.net> writes:
Walter wrote:

 "Burton Radons" <loth users.sourceforge.net> wrote in message
 news:bg0vpb$2om0$1 digitaldaemon.com...
 
Walter wrote:


"Burton Radons" <loth users.sourceforge.net> wrote in message
news:bg0r8t$2jh7$1 digitaldaemon.com...


This code:

   void main ()
   {
       Object foo;
       assert (foo);
   }

Compiles but has an "Error: Access Violation" on execution.
Correct, since foo is null.
Not correct, man. Assert is not behaving here in the same way as if, for, while, or the trinary operator. This test is implicitly defined as being equivalent to "foo !== null" in the Expressions/Cast Expressions section, and the AssertExpression definition gives no indication that it alters casting semantics for its special case.
So you argue it should give an AssertException rather than an access violation exception?
I argue that assert should be implemented in a way consistent with the rest of the logic statements.
Jul 27 2003