D - DMD 0.68 bug: Assert on object references causing an exception.
- Burton Radons <loth users.sourceforge.net> Jul 27 2003
- "Walter" <walter digitalmars.com> Jul 27 2003
- Burton Radons <loth users.sourceforge.net> Jul 27 2003
- "Walter" <walter digitalmars.com> Jul 27 2003
- Russ Lewis <spamhole-2001-07-16 deming-os.org> Jul 27 2003
- "Walter" <walter digitalmars.com> Aug 09 2003
- Russ Lewis <spamhole-2001-07-16 deming-os.org> Aug 10 2003
- "Walter" <walter digitalmars.com> Aug 16 2003
- Russ Lewis <spamhole-2001-07-16 deming-os.org> Aug 21 2003
- "Walter" <walter digitalmars.com> Sep 09 2003
- Burton Radons <loth users.sourceforge.net> Jul 27 2003
This code:
void main ()
{
Object foo;
assert (foo);
}
Compiles but has an "Error: Access Violation" on execution.
Jul 27 2003
"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
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
"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
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
"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?
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
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
"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?
idea is that accessing a null pointer generates a hardware exception.
runtime library turns the hardware exception into a D exception,
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
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
test for a null pointer and generate an exception? Let the hardware do
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
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
"Walter" <walter digitalmars.com> "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
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
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