D - DMD 0.68 bug: Assert on object references causing an exception.
- Burton Radons (7/7) Jul 27 2003 This code:
- Walter (3/10) Jul 27 2003 Correct, since foo is null.
- Burton Radons (6/21) Jul 27 2003 Not correct, man. Assert is not behaving here in the same way as if,
- Walter (4/25) Jul 27 2003 So you argue it should give an AssertException rather than an access
- Russ Lewis (3/35) Jul 27 2003 That's certainly what I expected it to do when I read the code!
- Walter (14/17) Aug 09 2003 I've had a similar long discussion with Matthew about things like this. ...
- Russ Lewis (5/28) Aug 10 2003 In what way do you interpret the assert such that it would cause a
- Walter (10/34) Aug 16 2003 The
- Russ Lewis (4/15) Aug 21 2003 Ok, that sounds reasonable. But is there any reason why it shouldn't
- Walter (4/19) Sep 09 2003 the
- Burton Radons (3/35) Jul 27 2003 I argue that assert should be implemented in a way consistent with the
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...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.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
"Burton Radons" <loth users.sourceforge.net> wrote in message news:bg0vpb$2om0$1 digitaldaemon.com...Walter wrote:So you argue it should give an AssertException rather than an access violation exception?"Burton Radons" <loth users.sourceforge.net> wrote in message news:bg0r8t$2jh7$1 digitaldaemon.com...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.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:bg0vpb$2om0$1 digitaldaemon.com...That's certainly what I expected it to do when I read the code! RussWalter wrote:So you argue it should give an AssertException rather than an access violation exception?"Burton Radons" <loth users.sourceforge.net> wrote in message news:bg0r8t$2jh7$1 digitaldaemon.com...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.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
"Russ Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message news:bg15ra$2ukf$1 digitaldaemon.com...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.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!
Aug 09 2003
Walter wrote:"Russ Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message news:bg15ra$2ukf$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?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.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!
Aug 10 2003
"Russ Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message news:bh62vo$21bt$1 digitaldaemon.com...Walter wrote:The"Russ Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message news:bg15ra$2ukf$1 digitaldaemon.com...I've had a similar long discussion with Matthew about things like this.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!The Didea is that accessing a null pointer generates a hardware exception.accessibleruntime library turns the hardware exception into a D exception,out,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 printedsoftwarein 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 extraittest for a null pointer and generate an exception? Let the hardware doAn assert on an object reference calls the invariant for that object. If the reference is null, it'll gp fault.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 16 2003
Walter wrote:"Russ Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message news:bh62vo$21bt$1 digitaldaemon.com...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.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 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:the"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. IfWhy bother if the hardware does it for you?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.
Sep 09 2003
Walter wrote:"Burton Radons" <loth users.sourceforge.net> wrote in message news:bg0vpb$2om0$1 digitaldaemon.com...I argue that assert should be implemented in a way consistent with the rest of the logic statements.Walter wrote:So you argue it should give an AssertException rather than an access violation exception?"Burton Radons" <loth users.sourceforge.net> wrote in message news:bg0r8t$2jh7$1 digitaldaemon.com...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.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