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