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
