Jump to page: 1 2 3
Thread overview
Acces Violation: assert with null instance
Jan 05, 2007
Lionello Lunesu
Jan 05, 2007
Lionello Lunesu
Jan 05, 2007
Lionello Lunesu
Jan 10, 2007
Stewart Gordon
Jan 10, 2007
Frits van Bommel
Jan 11, 2007
Stewart Gordon
Jan 11, 2007
Lionello Lunesu
Jan 11, 2007
Frits van Bommel
Jan 24, 2007
Walter Bright
Jan 24, 2007
Sean Kelly
Jan 26, 2007
Walter Bright
Jan 26, 2007
Sean Kelly
Jan 26, 2007
Frits van Bommel
Jan 26, 2007
Sean Kelly
Jan 26, 2007
Frits van Bommel
Jan 24, 2007
Frits van Bommel
Jan 26, 2007
Walter Bright
Jan 25, 2007
Bradley Smith
Jan 26, 2007
Walter Bright
Jan 26, 2007
Bradley Smith
Jan 26, 2007
Sean Kelly
January 05, 2007
I really think this used to work (like in C++) :

#class Class {}
#void main(){
#    Class c;
#    assert(c);
#}

With 1.0, I get an access violation in _D9invariant12_d_invariantFC6ObjectZv, but why? I have to rewrite it as assert(c !is null), but I don't recall having to do this before....

L.


January 05, 2007
Lionello Lunesu wrote:
> I really think this used to work (like in C++) :

..Guess not. I've just tested with some old versions, as old as 0.119, and I still got the Access Violation. Odd.

Shouldn't it work though?

Class c = null;
assert(c);

L.
January 05, 2007
Lionello Lunesu wrote:
> _D9invariant12_d_invariantFC6ObjectZv

For the record:

When linking against a debug build of Phobos (-unittest -g -w), I get:

Error: AssertError Failure internal\invariant.d(14)

Posted on bugzilla as Issue 796.

L.
January 10, 2007
Lionello Lunesu wrote:
> I really think this used to work (like in C++) :
> 
> #class Class {}
> #void main(){
> #    Class c;
> #    assert(c);
> #}
> 
> With 1.0, I get an access violation in _D9invariant12_d_invariantFC6ObjectZv, but why?
<snip>

For some strange reason, assert on an object reference checks that the invariants are satisfied instead of that the reference isn't null. There's nothing to this effect in the spec, so I don't know how it came about.  While it may be useful, it certainly shouldn't do it _instead of_ checking it isn't null.

Stewart.
January 10, 2007
Stewart Gordon wrote:
> For some strange reason, assert on an object reference checks that the invariants are satisfied instead of that the reference isn't null. There's nothing to this effect in the spec, so I don't know how it came about.  While it may be useful, it certainly shouldn't do it _instead of_ checking it isn't null.

As I commented recently when this bug was added to bugzilla, it's in the spec. It's just not where you'd expect it.
It's noted at http://www.digitalmars.com/d/class.html#invariants (the section on class invariants) instead of in the section on asserts.
I've since added a warning about this on the comments page for the page containing the section on asserts.

Also, the null check *is* in the code, but when Phobos is compiled in release mode (which the pre-compiled version is) the assert isn't performed...
January 11, 2007
Frits van Bommel wrote:
> Stewart Gordon wrote:
>> For some strange reason, assert on an object reference checks that the invariants are satisfied instead of that the reference isn't null. There's nothing to this effect in the spec, so I don't know how it came about.  While it may be useful, it certainly shouldn't do it _instead of_ checking it isn't null.
> 
> As I commented recently when this bug was added to bugzilla, it's in the spec. It's just not where you'd expect it.

What is the Bugzilla issue number?  I can't seem to find it.

> It's noted at http://www.digitalmars.com/d/class.html#invariants (the section on class invariants) instead of in the section on asserts.
> I've since added a warning about this on the comments page for the page containing the section on asserts.
> 
> Also, the null check *is* in the code, but when Phobos is compiled in release mode (which the pre-compiled version is) the assert isn't performed...

"The invariant can be checked when a class object is the argument to an assert() expression, as:"

I see this as giving an _additional_ use of assert, something that assert on a class object may do as an extra.  The general contract of assert is supposed to remain, and the fact that out of the box it doesn't certainly constitutes a bug, at least IMO.

Stewart.
January 11, 2007
Stewart Gordon wrote:
> Frits van Bommel wrote:
>> Stewart Gordon wrote:
>>> For some strange reason, assert on an object reference checks that the invariants are satisfied instead of that the reference isn't null. There's nothing to this effect in the spec, so I don't know how it came about.  While it may be useful, it certainly shouldn't do it _instead of_ checking it isn't null.
>>
>> As I commented recently when this bug was added to bugzilla, it's in the spec. It's just not where you'd expect it.
> 
> What is the Bugzilla issue number?  I can't seem to find it.

796

>> It's noted at http://www.digitalmars.com/d/class.html#invariants (the section on class invariants) instead of in the section on asserts.
>> I've since added a warning about this on the comments page for the page containing the section on asserts.
>>
>> Also, the null check *is* in the code, but when Phobos is compiled in release mode (which the pre-compiled version is) the assert isn't performed...
> 
> "The invariant can be checked when a class object is the argument to an assert() expression, as:"
> 
> I see this as giving an _additional_ use of assert, something that assert on a class object may do as an extra.  The general contract of assert is supposed to remain, and the fact that out of the box it doesn't certainly constitutes a bug, at least IMO.

I agree, that why I filed that bug :)

L.
January 11, 2007
Stewart Gordon wrote:
> "The invariant can be checked when a class object is the argument to an assert() expression, as:"
> 
> I see this as giving an _additional_ use of assert, something that assert on a class object may do as an extra.  The general contract of assert is supposed to remain, and the fact that out of the box it doesn't certainly constitutes a bug, at least IMO.

Huh. I must've read that wrong. I thought it said "is checked". I guess this one makes more sense. That definitely makes it a bug.
January 24, 2007
Stewart Gordon wrote:
> Lionello Lunesu wrote:
>> I really think this used to work (like in C++) :
>>
>> #class Class {}
>> #void main(){
>> #    Class c;
>> #    assert(c);
>> #}
>>
>> With 1.0, I get an access violation in _D9invariant12_d_invariantFC6ObjectZv, but why?
> <snip>
> 
> For some strange reason, assert on an object reference checks that the invariants are satisfied instead of that the reference isn't null. There's nothing to this effect in the spec, so I don't know how it came about.  While it may be useful, it certainly shouldn't do it _instead of_ checking it isn't null.
> 
> Stewart.

It does check if it's null. That's how the access violation exception gets thrown.
January 24, 2007
Walter Bright wrote:
> Stewart Gordon wrote:
>> Lionello Lunesu wrote:
>>> I really think this used to work (like in C++) :
>>>
>>> #class Class {}
>>> #void main(){
>>> #    Class c;
>>> #    assert(c);
>>> #}
>>>
>>> With 1.0, I get an access violation in _D9invariant12_d_invariantFC6ObjectZv, but why?
>> <snip>
>>
>> For some strange reason, assert on an object reference checks that the invariants are satisfied instead of that the reference isn't null. There's nothing to this effect in the spec, so I don't know how it came about.  While it may be useful, it certainly shouldn't do it _instead of_ checking it isn't null.
>>
>> Stewart.
> 
> It does check if it's null. That's how the access violation exception gets thrown.

But that's generated by the hardware, isn't it?  Shouldn't assert explicitly check whether c is null before calling its invariant?


Sean
« First   ‹ Prev
1 2 3