Home > Meetings >

Live Q&A - The Best Defense is Offensive Programming

Tyler Hoffman - Watch Now - Duration: 20:07

Live Q&A with Tyler Hoffman for the talk titled The Best Defense is Offensive Programming
italicssurround text with
boldsurround text with
**two asterisks**
or just a bare URL
surround text with
strikethroughsurround text with
~~two tilde characters~~
prefix with

Score: 0 | 5 months ago | no reply

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!

16:41:52	 From Michael Kirkhart : Avoiding bootloops may be difficult if you have asserts in low level (hardware interface) functions which are used both during initialization and during normal runtime.
16:42:22	 From Leandro Pérez : Hi everyone from Colombia
16:43:13	 From Leandro Pérez : Yes I too...lol
16:43:32	 From Rocco Brandi : I have run the video at 1.25x
16:44:00	 From Leandro Pérez : Me too... lol
16:44:15	 From Keith J : Changing my thought process as well.... interesting tie in with Steve's keynote and using asserts in production code to allow discovery of root cause of issues
16:44:48	 From Rob Meades : I used to follow this approach but what changed my mind was being in the position of being a technology supplier to someone else: the customer hated the idea of code written by a third party calling assert() of _any_ kind. They fixed it by re-stubbing every assert call through to their logging system of course.  Maybe the answer is to form an API of your offensive mechanisms.
16:44:48	 From Leandro Pérez : I believe that I understand for why reason there are many ASSERT in AWS FreeRTOS
16:45:40	 From Mark : Hey Tyler, thanks for the talk. What are your thoughts on having an overall system status that gets passed throughout the software and most functions use the common status? Some industrial devices use the HART communication protocol and have a HART status that's output to the user. I've seen the HART status used in low level functions where if the sensor reading fails, then a HART status is set to something like "Primary Variable Unavailable" and then that gets passed up to the user eventually.
16:45:59	 From jvillasante : I think asserting in application code it’s kind of fine if you can swallow that, but in library code it is not.
16:46:31	 From Raul Pando : Tyler, something I haven't quiet understood is when there is an assertion that causes a reset to the MCU, how is the context dumped into a core for later inspection, is that done during boot? process?
16:46:46	 From Leandro Pérez : yes... lol
16:46:51	 From Michael Kirkhart : Shall remain shameless?
16:47:33	 From Michael Kirkhart : That goes for any ARM CPU
16:47:36	 From Sam : Offensive programming feels like TDD (test driven dev)...true?
16:49:22	 From Raul Pando : Thanks
16:52:14	 From patelk5 : I work in the medical industry, is offensive programming such a good idea in production environment where failure has real consequences?
16:53:57	 From Nathan Jones : Great talk, Tyler! What's your take on including redundant asserts, such as asserting a parameter at each step in the call stack? I'm inclined to keep them in (to mostly protect against myself!), but I've read from some people that there's no need.
16:54:22	 From Nathan Jones : I mean, clearly there's no need. But maybe it's still a "good practice".
16:56:39	 From Keith J : @patelk5 - also medical industry here - you can still use assert to log and report while recovering... don't you want to know there is an issue?
16:57:06	 From Sam : thx
16:57:12	 From Erwin : @patelk5: What causes your device to have undefined behaviour will potentiall cause harm so at least you can assure sdafe state!
16:57:14	 From Bruce Lueckenhoff : Offensive programming seems very reminiscent of "Design By Contract" -- in addition to assert, DBC  has additional concepts:  pre-conditions, post-conditions, and invariants. Could you please compare Offensive Programming to Design-By-Contract.
16:57:58	 From Nathan Jones : Thanks!
16:58:06	 From Leandro Pérez : I remember the "Token" approach in my first C implementation before and after to call a method... it was in 2006
16:59:04	 From patelk5 : @keith J thanks for response. I am just curious about a system like an operating table. If you reset the system during surgery, the table would be unusable. Logs would still be useful, but wouldn't it be good to keep the system going?
16:59:33	 From Leandro Pérez : Thanks Tyler... Many changes for apply
16:59:33	 From Leandro Pérez : lol
16:59:39	 From Keith J : Thanks Tyler!
16:59:41	 From patelk5 : Thanks Tyler!
16:59:43	 From Charles Miller : 3pm meeting..gotta bail..THANK YOU Tyler.
16:59:44	 From Christopher Long : Thank you Tyler! Great talk.
16:59:45	 From Tyler Gilbert : Good job Tyler!
16:59:46	 From Matt Liberty : Thanks Tyler!
16:59:47	 From Bruce Lueckenhoff : Thanks Tyler!
17:00:01	 From David : Thanks Tyler!
17:00:10	 From Agnes B : Thanks Tyler
17:00:35	 From Will Hsiung : Thanks Tyler for your talk and Q&A
17:00:44	 From Sam : thank you
17:00:51	 From javi : I'm on it and it looks great!
17:00:57	 From javi : thanks Tyler
17:01:16	 From Leandro Pérez : bye