Defensive Programming

Author here. Firmware, for better and worse, is stuck in C&#x2F;C++ land, so many of the topics here are essential to keep a complex, multi-MCU, multi-board setup in working order.<p>I&#x27;m actually really curious what you all do in C&#x2F;C++ to <i>prevent</i> bad operations from ever being performed in the first place.<p>For example, should we just change our internal malloc &#x2F; free to use double pointers instead?<p><pre><code> bool malloc(size_t n, void **ptr) { *ptr = &lt;memory&gt; } void free(void **ptr) { ... &lt;free&gt; *ptr = NULL } </code></pre> This way, if anyone actually tries to use that pointer, it will crash the system (hardfault), instead of potentially using corrupted memory, which IMO is much worse.

In Erlang, instead of calling it Offensive Programming they call it &quot;Let it Crash&quot;.<p>A very valuable concept either way: if a function encounters an error and can&#x27;t somehow resolve it and still do its work successfully, then it should fail and not do something else.

I&#x27;ve worked in both embedded and in the Windows file system stack.<p>What&#x27;s unsaid in this article is that your ability to break noisily varies a lot based on what the end user&#x27;s expectations are and how much of the device you own.<p>If you&#x27;re building a single-purpose embedded device, sure, you can probably halt and catch fire if its use-case allows doing so safely. This might involve making sure the outside world is safely brought to a halt, but that might be feasible if you&#x27;re building a device that works on a production line.<p>On the other hand, you almost certainly don&#x27;t want to bugcheck some random big corporate file server that might be doing goodness knows what else to get a crash dump. At least not without the blessing of the client.<p>Like so many other things in engineering, how to handle errors depends greatly on the use case, the users, and the maintainers (which might or might not overlap with the users). You can&#x27;t baldly claim that one approach or another is best without understanding those.

As a side note, this article suggests using assert. Fine, but make sure you know what your assert does, and when it does that, if you have a debug and release build (which I think you probably shouldn&#x27;t.)<p>I&#x27;ve spent some time with &quot;offensive&quot; programming in the context of both security (like key leakage) and safety (like firmware integrity). It was just kinda funny thinking about meetings spent determining what we could do if i2c or something wasn&#x27;t responding, and different approaches to try and fix it, and then a year later going back and saying, ok, if something isn&#x27;t working, we&#x27;ve got an easy answer. Lockdown and halt boot. Anything seems weird, just stop trying.

The arguments of this article are ridiculously bad in my opinion.<p>Defensive programming does not mean that you ignore errors. It means that the dev should always expect the worse and decide right away how to deal with it early.<p>Imagine you have a car that suddenly block and explode each time an unexpected error is encountered. So that you are sure to catch it.<p>So, you are driving on the highway, then a there a window fuse that blow and because of that your car decide to brake and explode...<p>Especially in hardware and embedded, you have to expect the unexpected to happen.<p>Imagine the car will suddenly stop when a lightbulb break or there is a shortcut in windows control. Sure you will know, but you will have 300 000 cars all around the world bricked!

Well... in standard linux malloc never fails... not sure if it is a good thing though..

Excellent writeup and intro to the underdiscussed topic of offensive programming, and how DefP and OffP are not contradictory (any more than graceful fallback and rejection of bugs has to be), but rather applies to different categories of errors, with that crucial line of defense inbetween.<p><a href="http:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Offensive%20programming" rel="nofollow">http:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Offensive%20programming</a>

I was a python programmer before I became a c++ developer and believe it or not despite lack of type checking, big python apps have much less bugs then a comparable c++ app due in no part to offensive programming features built into python. In other words you don’t need to offensively program in python, it’s a given.<p>Firmware is just a pain in the ass to deal with. Wish there was a better way.