On Wednesday, 24 January 2018 at 03:46:41 UTC, lobo wrote:

> Well if your embedded device has all that on it you should be sitting on an OS with proper memory management support.

I don't see how the OS can help if the underlying hardware doesn't have an MMU.  That being said, admittedly, the more capable microcontrollers do have an MPU that can be configured to throw a hardware exception.

> We don't use D, it is all C++ and some Ada in the older systems.

Why don't you use D?

Mike

On Wednesday, 24 January 2018 at 04:15:27 UTC, Mike Franklin wrote:
> On Wednesday, 24 January 2018 at 03:46:41 UTC, lobo wrote:
>
>> Well if your embedded device has all that on it you should be sitting on an OS with proper memory management support.
>
> I don't see how the OS can help if the underlying hardware doesn't have an MMU.  That being said, admittedly, the more capable microcontrollers do have an MPU that can be configured to throw a hardware exception.
>

OK I'll state here that personally I don't agree with the segfault argument if the nullptr access can be detected at compile time. Anything that can be done at compile time should not be pushed out to runtime.

That said you can architect code so that nullptrs go away and the MMU is not necessary. E.g. no pointers and no allocations after main() are just two of a number of steps you can take. Good engineering works; in the 10yrs I've been with the Health Care Devices group we haven't had one memory corruption issue in a critical component. The last memory corruption issue we had in non-critcal was 4yrs ago, in older C++ code. Memory corruption really is becoming a thing of the past in modern C++.

Now the biggest problems for us are security  because everything has to be internet enabled!

>> We don't use D, it is all C++ and some Ada in the older systems.
>
> Why don't you use D?
>
> Mike

We're looking into D but at the moment but the general consensus is that the tooling is not mature enough on ARM (STM32) or Atmel AVR32 (used in our older devices). Rust is in the same boat.

We have ~250 devs and there are basically three groups, C/C++, D and Rust. But it pains me to say that all three groups agree that modern C++ is probably going to win in the end. And I'm broken after using D, going back to C++ is awful and Rust just has too much friction to be enjoyable.

bye,
lobo

On Wednesday, 24 January 2018 at 09:35:44 UTC, lobo wrote:
> The last memory corruption issue we had in non-critcal was 4yrs ago, in older C++ code. Memory corruption really is becoming a thing of the past in modern C++.

If you write everything from scratch with safety-oriented design?

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

On Wednesday, 24 January 2018 at 19:12:50 UTC, Steven Schveighoffer wrote:
> 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.

There's also:

c) Improve/split the language by introducing -dip25 / -dip1000 and hope that people interested in memory safety will migrate their code to it.

On Wednesday, January 24, 2018 21:24:16 Seb via Digitalmars-d wrote:
> On Wednesday, 24 January 2018 at 19:12:50 UTC, Steven
>
> Schveighoffer wrote:
> > 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.
>
> There's also:
>
> c) Improve/split the language by introducing -dip25 / -dip1000 and hope that people interested in memory safety will migrate their code to it.

Those really have nothing to do with null pointers though.

- Jonathan M Davis

On 1/23/2018 6:28 PM, Mike Franklin wrote:
> 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.

Ok, but are these devices with 0 being a valid address?

It seems weird to me that any sane modern CPU design that can access megabytes of memory would have 0 be a valid address.

On 1/23/2018 7:22 PM, Jonathan M Davis wrote:
> We need to do that anyway for the overly large
> objects (and unfortunately don't last I heard).

I put a limit in at one time for struct/class sizes to prevent this issue, but got a lot of pushback on it and it was reverted.

Perhaps we can revisit that - and have large struct/classes be allow only in non-@safe code.

In general, though, if you don't have struct/class object sizes larger than the protected memory at null, you're safe with null dereferences.

On Thursday, 25 January 2018 at 02:41:53 UTC, Walter Bright wrote:

>
> Ok, but are these devices with 0 being a valid address?
>
> It seems weird to me that any sane modern CPU design that can access megabytes of memory would have 0 be a valid address.

Yes, 0 is a valid address and typically points to ROM (http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0497a/CHDBIJJE.html).

"The initial stack pointer and the address of the reset handler must be located at 0x0 and 0x4 respectively." (http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0497a/CHDBIJJE.html)

So you read address 0, dereference it, and you're at the bottom of the stack.

Some microcontrollers have an MPU to mitigate this.  You can read one technique here:  http://nuttx.org/doku.php?id=wiki:howtos:stm32-null-pointer  But the MPU is an optional component, and many microcontrollers in the ARM Cortex-M family do not have one.

Mike

On Thursday, 25 January 2018 at 04:01:47 UTC, Mike Franklin wrote:

> "The initial stack pointer and the address of the reset handler must be located at 0x0 and 0x4 respectively." (http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0497a/CHDBIJJE.html)

Sorry!  Wrong link.  Try this one:  http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dai0179b/ar01s01s01.html