On Monday, November 19, 2018 5:30:00 PM MST Steven Schveighoffer via Digitalmars-d-learn wrote: > On 11/19/18 7:21 PM, Jordi GutiƩrrez Hermoso wrote: > > On Monday, 19 November 2018 at 21:52:47 UTC, Steven Schveighoffer wrote: > >> A null pointer dereference is an immediate error, and it's also a safe > >> error. It does not cause corruption, and it is free (the MMU is doing > >> it for you). > > > > Is this always true for all arches that D can compile to? I remember > > back in the DOS days with no memory protection you really could read OS > > data around the beginning. > > It's true for all OSes that D supports, and for most modern operating > systems, that run in protected mode. > > It would NOT necessarily be true for kernel modules or an OS kernel, so > that is something to be concerned about.
For @safe to function properly, dereferencing null _must_ be guaranteed to be memory safe, and for dmd it is, since it will always segfault. Unfortunately, as understand it, it is currently possible with ldc's optimizer to run into trouble, since it'll do things like see that something must be null and therefore assume that it must never be dereferenced, since it would clearly be wrong to dereference it. And then when the code hits a point where it _does_ try to dereference it, you get undefined behavior. It's something that needs to be fixed in ldc, but based on discussions I had with Johan at dconf this year about the issue, I suspect that the spec is going to have to be updated to be very clear on how dereferencing null has to be handled before the ldc guys do anything about it. As long as the optimizer doesn't get involved everything is fine, but as great as optimizers can be at making code faster, they aren't really written with stuff like @safe in mind. > >> Consistent segfaults are generally easy to figure out. > > > > I think I would still prefer a stack trace like other kinds of D errors. > > Is this too difficult? > > Yes and no. It's good to remember that this is a HARDWARE generated > exception, and each OS handles it differently. It's also important to > remember that a segmentation fault is NOT necessarily the result of a > simple error like forgetting to initialize a variable. It could be a > serious memory corruption error. Generating stack traces can be > dangerous in this kind of state. > > As I said, on Linux you can enable a "hack" that generates an error for > a null dereference. On Windows, I believe that it already generates an > exception without any modification. > > On other OSes you may be out of luck until someone figures out a nice > clever hack for it. > > And if it's repeatable, you can always run in a debugger to see where > the error is occurring. Also, if your OS supports core dumps, and you have them turned on, then it's trivial to get a stack trace - as well as a lot more of the program state. - Jonathan M Davis