Hacker News Reader

MISRA is sometimes unfairly shat on, sure, but some things do require you to use your brain.

Regarding magic numbers, if my memory is not playing tricks on me, MISRA does not include 0 or 1 as magic numbers. Regardless, 1 is 1 regardless the number system you work in, I have never ever seen someone "yes, let's make 1 not be 1" (not in a sane way at least) and defining stuff like that for "improved flexibility" is an antipattern in my book. It makes code bigger, harder to navigate and understand. That kind of code does unexpected stuff, is hard to work with and has more bugs. The less surprises, the less indirection I get in a code base, the better. I also feel it makes refactoring harder not easier. I speak from experience, I've worked with codebases like that, they suck. (Hello Vector, if anyone working for them is out there!)

#define ONE 1 is bad code.

good code would be #define MAX_FOO 1 #define TOTAL_SUPPORTED_BAR_COUNT 1 #define STATUS_BYTE_OFFSET 1

The important thing there is even though all are one we have both given them a unique name, and indicated why they are one.

> Very common, and you can't ever mess up freeing memory.

Except that where misra is applied, there often is no dynamic allocation at all.

Most of the times, not always. They sometimes don't use malloc or free but their own special little memory pools.

From my experience in automotive, the ISO standard is against dynamic allocation if your system is classified high enough in terms of their safety levels.

As an example, we weren't allowed to use the C++ string class, and had to find a "safer" string class for C++.

(Not sure about MISRA - most of my experience is with the ISO standard, and MISRA is not mandated by it).

Yeah, so what they do is they don't use free and malloc, but use a bunch of buffers they free. Tadaa! We don't have dynamic allocation, just buffers, see? I've seen it, I can count in AUTOSAR systems like... 20 different hand spun allocators, 10 ques and 50 special little hierarchical state machines.

Forgive my lack of exposure to safety-critical C, but without dynamic allocation how does a program handle large state with indeterminate lifetimes? Or when you need a temporary buffer that’s too big to live on the stack?

You make the stack bigger. You might think I'm joking, but I'm not.

Or you make it static. You can work around it just fine.

> but without dynamic allocation how does a program handle large state with indeterminate lifetimes?

If you haven't, I strongly encourage taking a workshop/course on requirements engineering (not specific to SW nor safety). One thing that stood out is a requirement that says things like "indeterminate" or "large" are red flags. A requirement should state bounds on what sizes it should handle.

> Or when you need a temporary buffer that’s too big to live on the stack?

Do you have an example of where this may occur in a safety critical system?

I've forgotten the details, but many/most forbidden things are allowed in the code provided you have watchdogs for mitigation - so if things did fail it could safely shut down. I don't recall if dynamic allocation fell into that category.

large state is too complicated and error prone. cut it down.

don't put big temp. buffers onto the stack, put them into your .data segment. (i.e. global).

> In C, you have to be really careful with your flow control and memory allocations

I was going to ask if an early return could still be called "early" if there were resources to free, but I would say error checking after locking an object would still qualify (releasing the lock being necessary).

C++ helps with this with RAII.

> 2. No magic numbers. > > Another person complains about not being able to do magic numbers. While it can get tedious, you really shouldn't. They use the most insane example of #define ONE 1. BUT, even in this case you can argue that if the requirements were changed for a base 8 or other numbers system, you could easily port the app by just changing these define macro's rather than scouring through the code. It's not that tedious, and it can make the codebase more flexible and solve issues and porting.

I agree with you on magic numbers in general, but there have to be practical limits.

I was paid to deliver tight production code that was performant, often interfacing with assembly because that was what we had to do with the cheap micro our project used. I wasn't worried about other number systems, it wasn't worth spending R&D $$$ to make the code compatible with other number systems. I'm not writing code that will last 100 years. I deliver to schedules and budgets. Your arguments strike me as a bit too rigid, too academic. Not practical in the real world.

In my mind

   if (condition)
     num_found = num_found + 1

is clearly superior than this MISRA version

   if (condition)
     num_found = num_found + ONE

Because the first case is the simplest implementation, incredibly explicit as it. We're counting something. That's abundantly clear.

The second case is inferior because, as a reviewer doing their job, I have to go and lookup what ONE actually is. In case someone defined it weird. I start thinking "Maybe it's not 1, maybe it's 1.0". or "maybe its fixed point like (1.0 * 256)."

The moment I'm wondering what ONE is actually defined as, I'm no longer thinking about the code I'm reviewing. I have to interrupt my mental process to go find ONE, understand that, and then come back and pick up with what I was reviewing.

This stuff matters. Clarity matters. When 1 might not be 1, well then I have to think harder. Compounded, all these little complications dilutes the quality of the code overall. And programmer resources and time are limited.

Also, not to nitpick but your example "goto cleanup" is also not MISRA compliant. I'd argue that use of gotos is a greater sin than returning early.

I'm pragmatic. I've used gotos, where it makes sense, which is almost never. But never say never. Gotos are nearly always bad. Early returns are useful sometimes. Assembly should be avoided when possible.

Code is a tradeoff. When writing interrupt service routines, performance matters, and I found this is where I broke the MISRA rules the most. Because the code had to be tight. That was the value my company brought to the customer. We could get out of the interrupt quick enough to guarantee deadlines in the rest of the code. You do this by letting yourself write complex code in some places, the places that matter. And you scrutinize those more than you do the rest of the code.

MISRA (as misapplied by mid level managers) pretends the above statement doesn't matter.