Error: null dereference in function _Dmain
Namespace
rswhite4 at googlemail.com
Mon Jul 2 14:08:48 PDT 2012
> If you want to play around with that, that's fine, but the
> language is not
> going to change, so please to post code which uses your
> changes. If you start
> making changes to the compiler, you can't really expect other
> people to help
> you figure out what's wrong with your code - especially since
> your changes
> could be causing your problems (though I think that that's
> unlikely in this
> particular case).
Yes, sorry for that, it wasn't my intetion, i forgot (it was my
own test case for that compiler change)
> Okay. I missed that, but that's probably your problem then. The
> definitions of
> of Foo and NotNull are recursive, which I don't believe is
> legal.
You mean it's illegal that i have two "alias this" in both, the
Fo class and the NotNull struct?
I hope that this case would be never illegal.
And as i understood kenjii, he works on a fix that solves the
problem with the infinity loop.
> It's almost certainly what's causing the compiler to eat up
> tons of CPU and memory and
> then die. In fact, if I fix the issue with Ptr returning a
> pointer to a class,
> and remove Foo's alias this and its associated function, the
> code compiles
> just fine with
>
> test_normal_foo(f2);
>
> uncommented. Which in and of itself is disturbing, since
> there's no implicit
> conversion anymore. So, I think that there's definitely a bug
> there beyond the
> weird error that you're seeing.
But this was my intention: that Foo is implicit convertable to
NotNull!(Foo) and that NotNull!(Foo) is implicit convertable to
Foo.
> However, the compiler doesn't even do that right now, so I
> don't know why
> you're getting the complaint about null dereferencing that
> you're getting.
That's too bad.
> Actually, it looks like it had been a few days since I updated
> my compiler.
> Now, if all I do is change Ptr to
>
> @property
> auto Ptr() {
> static if (isPointer!(T) || is(T == class)) {
> return this._val;
> } else {
> return &this._val;
> }
> }
I get only a msg, that it doesn't compile.
But this works fine:
static if (is(T _unused : U*, U)) {
@property
inout(T) Ptr() inout {
return this._val;
}
} else {
@property
inout(T*) Ptr() inout {
return &this._val;
}
}
> then I get a segfault instead of dmd eating up CPU and memory,
> which is an
> improvement but not really acceptable, since the compiler isn't
> supposed to
> segfault. I don't know what the state of your bug report is, so
> I don't know
> if it's considered fixed or not.
>
> - Jonathan M Davis
Here it is:
http://forum.dlang.org/thread/bug-7980-3@http.d.puremagic.com%2Fissues%2F
More information about the Digitalmars-d-learn
mailing list