Jump to page: 1 2
Thread overview
[Issue 4595] New: Accessing non-static member of a null reference compiles
Aug 08, 2010
Andrej Mitrovic
Aug 08, 2010
Andrej Mitrovic
Aug 08, 2010
nfxjfg@gmail.com
Aug 08, 2010
nfxjfg@gmail.com
Aug 08, 2010
Jonathan M Davis
Aug 08, 2010
nfxjfg@gmail.com
Aug 08, 2010
Andrej Mitrovic
[Issue 4595] [tdpl] Accessing non-static member of a null reference compiles
Sep 17, 2013
Andrej Mitrovic
Sep 19, 2013
Kenji Hara
Sep 19, 2013
Andrej Mitrovic
August 08, 2010
http://d.puremagic.com/issues/show_bug.cgi?id=4595

           Summary: Accessing non-static member of a null reference
                    compiles
           Product: D
           Version: D2
          Platform: Other
        OS/Version: Windows
            Status: NEW
          Severity: normal
          Priority: P2
         Component: DMD
        AssignedTo: nobody@puremagic.com
        ReportedBy: andrej.mitrovich@gmail.com


--- Comment #0 from Andrej Mitrovic <andrej.mitrovich@gmail.com> 2010-08-07 17:02:48 PDT ---
This should not compile, DMD should detect that I'm trying to access a member of a null reference (stated in TDPL):

class A
{
    int x = 42;
}

unittest {
    A a;
    a.x = 5;
}

void main()
{
}

Runtime error:
object.Error: Access Violation

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
August 08, 2010
http://d.puremagic.com/issues/show_bug.cgi?id=4595



--- Comment #1 from Andrej Mitrovic <andrej.mitrovich@gmail.com> 2010-08-07 17:05:41 PDT ---
And an additional example:

class A { int x; }

unittest {
    A a;
    assert(__traits(compiles, a.x = 5));
}

void main() { }

Compiles and runs succesfully. assert should fail.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
August 08, 2010
http://d.puremagic.com/issues/show_bug.cgi?id=4595


nfxjfg@gmail.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |nfxjfg@gmail.com
         Resolution|                            |INVALID


--- Comment #2 from nfxjfg@gmail.com 2010-08-07 18:46:05 PDT ---
You're obviously free to cause all access violation you want. dmd never prevented that, and no non-nullable references feature is planned.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
August 08, 2010
http://d.puremagic.com/issues/show_bug.cgi?id=4595


bearophile_hugs@eml.cc changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bearophile_hugs@eml.cc


--- Comment #3 from bearophile_hugs@eml.cc 2010-08-07 19:21:57 PDT ---
You are mostly right nfxjfg, but please don't be harsh with people that use their time to submit problems in Bugzilla :-)

See enhancement request bug 4571 for a start of a proposal about non-null types modifier in D. It needs more work, of course.

And even if D will never have non-null references in its type system, DMD is already able to catch cases like this, if you compile it with -O:

class Foo { int x; }
void main() {
    Foo f;
    f.x = 5;
}


dmd 2.047 doesn't show a run-time sefault, it prints at compile-time: test.d(4): Error: null dereference in function _Dmain

So adding few more logic to the compiler to catch other common cases of uninitialized bugs is not inconceivable. The case shown in this bug reports are well within the capabilities of a short analysis, good lint tools are able to warn against far more complex cases. So I think this enhancement request should be reopened.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
August 08, 2010
http://d.puremagic.com/issues/show_bug.cgi?id=4595



--- Comment #4 from nfxjfg@gmail.com 2010-08-07 19:51:33 PDT ---
(In reply to comment #3)
> dmd 2.047 doesn't show a run-time sefault, it prints at compile-time: test.d(4): Error: null dereference in function _Dmain

I'd consider that a codegen bug. What if my program's semantics depend on the segfault?

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
August 08, 2010
http://d.puremagic.com/issues/show_bug.cgi?id=4595


Jonathan M Davis <jmdavisProg@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jmdavisProg@gmail.com


--- Comment #5 from Jonathan M Davis <jmdavisProg@gmail.com> 2010-08-07 20:37:32 PDT ---
No offense, but relying on a segfault seems rather silly. And if you really need one, I'm sure that you could easily produce one which the compiler can't catch (probably all it would take would be a function which returned null being used to initialize the variable rather than just declaring the variable).

I think that it's perfectly reasonable for dmd to catch simple and obvious cases where a null reference or pointer is going to be dereferenced. In other languages trying to be safe (such as Java or C#), they do enough code analysis to scream at you if do something like that and force you to initialize the variable. D goes the route of default initialization to the closest thing to an error value rather than forcing you to initialize variables before they're used, but I think that it's perfectly reasonable for the compiler to catch simple and obvious cases and scream at you about them. I believe that the main reason that dmd doesn't do it in the general case is because it's too hard for the compiler to accurately catch more complex cases without making the compiler much more complex in its code flow analysis (and Walter doesn't want that kind of complexity).

There's no question that you cannot rely on the compiler to catch all of the references and pointers that you forgot to initialize, but I see nothing wrong with it catching some of them.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
August 08, 2010
http://d.puremagic.com/issues/show_bug.cgi?id=4595


bearophile_hugs@eml.cc changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|INVALID                     |
           Severity|normal                      |enhancement


--- Comment #6 from bearophile_hugs@eml.cc 2010-08-07 21:02:16 PDT ---
> What if my program's semantics depend on the segfault?

That means relying on undefined or OS/machine-dependant behaviour. You are not programming in D any more.

I reopen this, but as enhancement request, because while I don't think that Walter will implement this very soon, it's a legit feature request for a D compiler to catch at compile-time one more case of uninitialized object reference.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
August 08, 2010
http://d.puremagic.com/issues/show_bug.cgi?id=4595



--- Comment #7 from nfxjfg@gmail.com 2010-08-07 21:46:00 PDT ---
(In reply to comment #6)
> That means relying on undefined or OS/machine-dependant behaviour. You are not programming in D any more.

Then what is supposed to happen on a null reference access in D according to your opinion?

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
August 08, 2010
http://d.puremagic.com/issues/show_bug.cgi?id=4595



--- Comment #8 from bearophile_hugs@eml.cc 2010-08-08 06:00:38 PDT ---
Generally the D program stops, some things happen deterministically inside the GC and the D code and the underlying C runtime, some events happen to the threads of your D code in a partially deterministic way, but then what exactly happens is specified by the Operating System and Memory Management Unit of your computer.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
August 08, 2010
http://d.puremagic.com/issues/show_bug.cgi?id=4595



--- Comment #9 from Andrej Mitrovic <andrej.mitrovich@gmail.com> 2010-08-08 09:16:57 PDT ---
This is not a feature request. The TDPL specifically states that in *simple* cases such as these, DMD should flag this as an error. Otherwise if it can't figure out if it indeed is a null-reference, it will compile and let the user handle it.

I usually compile with all warnings on. Thanks for the -O trick, bearophile. I never thought adding optimizations can catch bugs like that. :)

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
« First   ‹ Prev
1 2