Shouldn't invalid references like this fail at compile time?

[Steven Schveighoffer]

On 1/23/18 9:28 PM, Mike Franklin wrote:
> On Wednesday, 24 January 2018 at 01:44:51 UTC, Walter Bright wrote:
> 
>> Microcontroller code tends to be small and so it's unlikely that 
>> you'll need to worry about it.
> 
> I think you need to get involved in programming microcontrollers again 
> because the landscape has changed drastically.  The microcontrollers I 
> use now are more powerful than PCs of the 90's.
> 
> The project I'm currently working on is an HMI for industrial control 
> with a full touchscreen 2D GUI.  The code base  is 240,084 lines of code 
> and that doesn't even include the 3rd party libraries I'm using (e.g. 2D 
> graphics library, newlib C library, FreeType font rendering library).  
> That's not "small" by my standard of measure.
> 
> And with devices such as this being increasingly connected to the 
> Internet, such carelessness can easily be exploited as evident in 
> https://en.wikipedia.org/wiki/2016_Dyn_cyberattack   And that's not to 
> mention the types of critical systems that run on such platforms that we 
> are increasingly becoming more dependent on.
> 
> We better start worrying about it.

While I understand your argument, the truth is that avoiding null 
dereferencing *statically* has to be built into the language from the 
beginning. As D is already too far along to retrofit this, your 2 
options are:

a) instrument the code, as Jonathan suggests (every dereference checks 
for null ahead of time).

b) restrict your code, design, and functions that you use to ensure null 
pointers cannot happen.

a) is something we could implement in D, and I think it might make sense 
as a specialized version of the compiler for certain situations. b) is 
something you can do in any language, and D gives you much of the tools 
to do so.

Even implementing features of the compiler to help with option b is 
feasible, but I don't know what that is.

An example that is slightly unrelated but on the same path: D arrays 
throw an error when you access an out-of-bounds value. An error is not 
recoverable, which means that the entire process has to die, or face 
undefined behavior.

For vibe.d programs, this means killing the whole server if one route is 
implemented incorrectly. While you can restart the server, any 
in-progress calls will also be killed, unnecessarily.

My solution to this was to create an array type that decays to a real 
array, but where out-of-bounds indexing throws an exception instead. I 
just have to be diligent about using this array type anywhere it might 
be an issue, and the problem is solved. And in fact, it was quite easy 
to do, due to the awesome powers of introspection in D.

-Steve