Why does nobody seem to think that `null` is a serious problem in D?

H. S. Teoh hsteoh at quickfur.ath.cx
Sat Dec 1 19:02:54 UTC 2018


On Sat, Dec 01, 2018 at 06:30:05PM +0000, Tony via Digitalmars-d-learn wrote:
> On Saturday, 1 December 2018 at 11:16:49 UTC, Dukc wrote:
> > This is great when it works, but the problem is that it would be
> > gargantuan effort -and compile time sink- to make it work perfectly.
> > When it's just about if-else if chains, switches or boolean logic as
> > in the example, the analysis won't be too complicated. But swap
> > those booleans out for a string, and make the conditions to test
> > whether it's a phone number, and whether it satisfies some predicate
> > implemented in a foreign language, and you'll see where the problem
> > is.
> 
> I think he is just talking about the compiler or static analyzer
> seeing if a variable has been given a value before it is used, not if
> it was given a valid value.

But that's precisely the problem. It's not always possible to tell
whether a variable has been initialized. E.g.:

	int func(int x) {
		int *p;

		if (solveRiemannHypothesis()) {
			p = &x;
		}

		...

		if (solveArtinsConjecture()) {
			*p++;
		}
		return x;
	}

For arbitrarily complex intervening code, determining whether or not a
certain code path would take (that would initialize the variable) is
equivalent to solving the halting problem, which is undecidable.

In the above contrived example, Artin's conjecture is implied by the
Riemann hypothesis, so the second if statement would only run if p is
initialized. But there is no way the compiler is going to be able to
deduce this, especially not during compile time. So it is not possible
to correctly flag p as being initialized or not when it is dereferenced.

Therefore, leaving it up to the compiler to detect uninitialized
variables is unreliable, and therefore any code that depends on this
cannot be trusted. Code like the above could be exploited by a
sufficiently sophisticated hack to make the uninitialized value of p
coincide with something that will open a security hole, and the compiler
would not be able to reliably warn the programmer of this problem.

Uninitialized variables are *not* a good thing, contrary to what the
author of the article might wish to believe.


T

-- 
The computer is only a tool. Unfortunately, so is the user. -- Armaphine, K5


More information about the Digitalmars-d-learn mailing list