Live Q&A - The Best Defense is Offensive Programming
Thanks for a great talk. Which pressure sensor gave you problems at higher altitudes? I'm looking at BMP390 and a couple others...
Assuming you use malloc_assert() of times, would it be more efficient to make it into a macro, that would be replaced at compile time, than jumping to the function in runtime?
That's a good idea! I'm generally against macros that hide or change functionality and don't mind the extra function call in most cases. You could consider forcing inlining through your compiler options which would have the same benefit but not be a macro.
Very good talk. I am also a fan of these offensive programming techniques. It may sound strange, but have you had to defend the offense; have you had to worry about offensive programming techniques in a critical application scenario. An example would be life support systems, or maybe autonomous driving systems. The reset is not, or less tolerable in these applications. Are there other offensive programming techniques (not hardware based) you would use here?
Personally, I need to dig in more myself and understand what is and isn't allowed in certain types of firmware / devices. I'd argue that letting a firmware continue to run with bugs occurring / corruption / undefined behavior is much, much worse than just resetting the system, especially if the device reboots on the order of milliseconds and can pick up from where it left off on boot.
We talked a little about recovering from faults without resetting the MCU in this Interrupt blog post: https://interrupt.memfault.com/blog/cortex-m-fault-debug#recovering-from-a-fault
I think for critical sections, it's probably OK to lessen the severity of the asserts and make them high-priority logs, but just make sure to track them! Understand why they are still being hit, aggregate and count them, and understand why they are happening. When testing internally, do escalate the issue and really dig into why it's happening.
Bug Report: @ 22 minutes
if (!name|| name_len > 32)
You said if name length is too small it is bad, but this looks to see if the length is too big
Awesome discussion Tyler! Thank you.
Hi Tyler, the talk and Q&A was very interesting and definitely worthy of being included at the conference, IMHO. I tend to be the only one in my team using assert occasionally, but I?ll try now to sprinkle much more in! What I?ve seen a lot in my career is that a function/method provides a return code, but then it?s often never checked by the caller somewhere in the middle of the stack, effectively swallowing the error. I guess that?s why exceptions make sense in the non-embedded world, as they?re harder to ignore. Different people writing their bit of the code often have their own coding style, such as return bool, -1 or an enum, so there?s often a proliferation of different statuses all meaning the same thing, but often the meaning gets lost like a game of Chinese whispers going up the stack. I often return a bool ok, as it?s human readable what it means and easy to logical AND to daisy chain several. But yes, fail faster with asserts and fix the code , so it doesn?t happen again is best. Thanks again!