5 ms·

Reminds me of the period in my career I was doing contract work for automotive. I used to work in airbag, highly safety critical real-time stuff, so I knew my w

Reminds me of the period in my career I was doing contract work for automotive. I used to work in airbag, highly safety critical real-time stuff, so I knew my way around these kinds of systems. Mandate came down from customer everything was to be MISRA compliant. Which is great for about 1/2 of your code, just common sense stuff. Like int DebounceVal[NUM_DEBOUNCE_SIGNALS]; For the other half it's essentially impossible, especially when you're writing your own custom tasker/OS (really just a main loop with interrupts) with some simple system calls. The way things were done back then on small 8 and 16-bit systems. You will have serious deviations. There's just no way to disable interrupts without some assembly somewhere. The "non-programmer" types at our customer kept kicking the code back for not being MISRA compliant. So I had to go through a lot of iterations "fixing" things. Led to code that looked like this if (k > ZERO) ... n = n + ONE; tens_digit = num % TEN; hundreds_digit = num % ONE_HUNDRED; You get the picture. So code reviews really added no value, because instead of reviewing code (remember these weren't programmers) they just complained about what some automated tool was saying. After several back and forths I got so sick of things I created a file called MISRA.h to collect all the nonsense defines like this. #define ZERO 0 #define ONE 1 #define TWO 2 ... #define ONE_HUNDRED 100 As a joke I put this in the title block // MISRAble.h // (c) copyright blah blah blah Which of course their eagle eyes caught that, and so the comment itself got flagged by the customer as an open issue. Guess I deserved that one. Funny thing was that they had to track the issue, meeting by meeting, until it was closed out. I think the action item was something like "Remove inappropriate comment from MISRA.h" lol. As someone else pointed out here... LINT was the bomb. Made code so much better. Especially when you could do stuff like this switch (something) case A ... // yes I know I'm falling through to case B //lint -fallthrough case B: ... Once you got in the habit of appeasing LINT, your code was not only more readable but more explicit. Good times.

smaudet 3y ago
> Once you got in the habit of appeasing LINT, your code was not only more readable but more explicit. I get the hate, however: A) C/C++ sucks at interop. I don't mean C++01 vs C++13 vs C++15 vs C++17 vs C++19 (and good luck if your project doesn't explicitly specify which type of compiler it needs), I mean Visual Studio vs GCC vs LLVM vs 30 different build flags, compiler versions, target architectures, ABI and caller conventions, linker foibles and just generally one of the most buggy toolchains in existence. A tool like MISRA C doesn't save you from all that exactly, but having a standard at all is important _especially_ when doing security/safety stuff. In VM (Java/NET/Python/JS) world you have to worry about some library calls and maybe bytecode compatibility, the amount of stuff you don't have to think about is just staggering. In C/CPP you need to be both disciplined and explicit to safely do just about anything. B) Formally provable systems are the dream. Linter rules do wonders for catching common issues, but they don't catch real bugs very often. The downside of systems like MISRA C etc. is they install a false sense of security "oh it passed the tool so it must be good". In fact you are just _automating ignoring watching for issues_, and worse _obfuscating the code so finding issues is harder_. But this is why we all hope(d) Rust/Go would save us and produce more reliable software, more cheaply.
- lordfrito 3y ago
  C is a very powerful but very primitive language. Too easy to do all sorts of things you didn't intend. But C was all we had (we didn't even have C++), and we had to use it, and use it effectively to deliver production firmware that couldn't change after it was shipped. We used it, and we got good at it, and we loved it. And we hated it because we used it and loved it, and that gave us the right to hate it. Like my above example, when looking at tight (production, performant) C code, you always ask "did the programmer mean to do that?" or "was the programmer aware of the side effect" etc. Once I groked LINT, I understood that the comments which appeased LINT were also messages to us humans that the programmer had considered the side effects, etc. and that this was intended behavior. Made it easier to look at other people's code, heck even my old code, because it told me that "yeah, this was considered". Saved a lot of guess work, and allowed me to look at the meat of the code and not be distracted by the simple error stuff. Also, as much as I love C, my biggest complaint is that it should have been strongly typed from the very start. C# gets this right. You have to be very explicit about mangling things in C#. In straight C it's just too easy to mix types and mess simple stuff up. The compilers attitude is, "sure.. I'll compile that". I prefer it asking questions and complaining.
  - pjmlp 3y ago
    In what world? I have been coding since 1986 and there were systems were C wasn't even an option, and others were C was an option among many others, excluding UNIX's early days before it got widespread outside AT&T. Even on embedded, besides Assembly, Forth, BASIC and Pascal have been a companion to C since high level languages are able to target those tiny CPUs. Naturally, I guess there were those systems were the specific vendor only provided a C SDK, which by the end of the MS-DOS days was already rare.
    - lordfrito 3y ago
      You're taking me too literally. Of course we had assembly, etc. The kind of development we were working on was safety-critical real-time systems. So assembly is too low level, too risky, you want something more structured. But nothing academic, or insanely expensive. BASIC just isn't up for the task? How do you even write an ISR in BASIC anyways? We had to read two sensors and process a bunch of math every 500 usec, which was like 500 cycles. Every cycle count. C was for sure the best choice that fit the bill. Plus, everyone knew it. Many times you didn't even get a fully ansi compliant compiler (try writing C on a PIC micro without a software stack). So, for a while, C ruled in places that mattered. Low cost, performant, and people knew the language. Also, the compilers we used were purchased from small software vendors, and delivered by mail on floppy discs (this is before the internet took off). Like $3000 for the compiler, a big investment for a small company in 1995. This was back before semiconductor companies had low cost dev tools with free IDEs. The tools we had were state of the art, expensive, and powerful for their time. We grew to love them, and learned how to work with them better.
BeetleB 3y ago
The problem wasn't MISRA, but your management. I've worked with the ISO standards for automotive. You can have exceptions to most rules as long as you have a justification that an independent auditor can agree with. Oh, and the ISO standards don't mandate MISRA. It's just one option. Also, the rules only apply where safety is relevant. If you can convincingly show that violating some rule won't affect safety, you were good to go. There are some pretty hefty rules, though. No recursion. No dynamic allocation unless it can't be avoided (and performance/optimization is not a valid excuse).
- lordfrito 3y ago
  > The problem wasn't MISRA, but your management. Agreed. But it was my customers management. And the customer is always right yada yada. So instead of using MISRA to help produce a better deliverable, it gets used as cudgel, a blunt instrument with which to beat programmers with, to create metrics that show the managers are effective at managing. In these cases, code quality necessarily suffers as a result. Because your resource constrained team has to spend more and more time on busywork. In my mind, LINT is a better tool than MISRA, because all tools can and will be abused by management, but some tools are more easily abused than others.
  - BeetleB 3y ago
    Why did your customer have access to your source code? Or was it the case that they didn't but they could access MISRA reports?
    - lordfrito 3y ago
      We were under contract to deliver them a working design, both hardware and software, which they would then manufacture. Basically outsourced R&D. So software was part of the deliverable. It was their product, their risk, after all. We didn't do this for long, just to pay the bills until we had our own products that were making us money.
      - 3y ago
glitchc 3y ago
Such a great story! Thank you for sharing.

smaudet 3y ago

> Once you got in the habit of appeasing LINT, your code was not only more readable but more explicit. I get the hate, however: A) C/C++ sucks at interop. I don't mean C++01 vs C++13 vs C++15 vs C++17 vs C++19 (and good luck if your project doesn't explicitly specify which type of compiler it needs), I mean Visual Studio vs GCC vs LLVM vs 30 different build flags, compiler versions, target architectures, ABI and caller conventions, linker foibles and just generally one of the most buggy toolchains in existence. A tool like MISRA C doesn't save you from all that exactly, but having a standard at all is important _especially_ when doing security/safety stuff. In VM (Java/NET/Python/JS) world you have to worry about some library calls and maybe bytecode compatibility, the amount of stuff you don't have to think about is just staggering. In C/CPP you need to be both disciplined and explicit to safely do just about anything. B) Formally provable systems are the dream. Linter rules do wonders for catching common issues, but they don't catch real bugs very often. The downside of systems like MISRA C etc. is they install a false sense of security "oh it passed the tool so it must be good". In fact you are just _automating ignoring watching for issues_, and worse _obfuscating the code so finding issues is harder_. But this is why we all hope(d) Rust/Go would save us and produce more reliable software, more cheaply.

lordfrito 3y ago
C is a very powerful but very primitive language. Too easy to do all sorts of things you didn't intend. But C was all we had (we didn't even have C++), and we had to use it, and use it effectively to deliver production firmware that couldn't change after it was shipped. We used it, and we got good at it, and we loved it. And we hated it because we used it and loved it, and that gave us the right to hate it. Like my above example, when looking at tight (production, performant) C code, you always ask "did the programmer mean to do that?" or "was the programmer aware of the side effect" etc. Once I groked LINT, I understood that the comments which appeased LINT were also messages to us humans that the programmer had considered the side effects, etc. and that this was intended behavior. Made it easier to look at other people's code, heck even my old code, because it told me that "yeah, this was considered". Saved a lot of guess work, and allowed me to look at the meat of the code and not be distracted by the simple error stuff. Also, as much as I love C, my biggest complaint is that it should have been strongly typed from the very start. C# gets this right. You have to be very explicit about mangling things in C#. In straight C it's just too easy to mix types and mess simple stuff up. The compilers attitude is, "sure.. I'll compile that". I prefer it asking questions and complaining.
- pjmlp 3y ago
  In what world? I have been coding since 1986 and there were systems were C wasn't even an option, and others were C was an option among many others, excluding UNIX's early days before it got widespread outside AT&T. Even on embedded, besides Assembly, Forth, BASIC and Pascal have been a companion to C since high level languages are able to target those tiny CPUs. Naturally, I guess there were those systems were the specific vendor only provided a C SDK, which by the end of the MS-DOS days was already rare.
  - lordfrito 3y ago
    You're taking me too literally. Of course we had assembly, etc. The kind of development we were working on was safety-critical real-time systems. So assembly is too low level, too risky, you want something more structured. But nothing academic, or insanely expensive. BASIC just isn't up for the task? How do you even write an ISR in BASIC anyways? We had to read two sensors and process a bunch of math every 500 usec, which was like 500 cycles. Every cycle count. C was for sure the best choice that fit the bill. Plus, everyone knew it. Many times you didn't even get a fully ansi compliant compiler (try writing C on a PIC micro without a software stack). So, for a while, C ruled in places that mattered. Low cost, performant, and people knew the language. Also, the compilers we used were purchased from small software vendors, and delivered by mail on floppy discs (this is before the internet took off). Like $3000 for the compiler, a big investment for a small company in 1995. This was back before semiconductor companies had low cost dev tools with free IDEs. The tools we had were state of the art, expensive, and powerful for their time. We grew to love them, and learned how to work with them better.

BeetleB 3y ago

The problem wasn't MISRA, but your management. I've worked with the ISO standards for automotive. You can have exceptions to most rules as long as you have a justification that an independent auditor can agree with. Oh, and the ISO standards don't mandate MISRA. It's just one option. Also, the rules only apply where safety is relevant. If you can convincingly show that violating some rule won't affect safety, you were good to go. There are some pretty hefty rules, though. No recursion. No dynamic allocation unless it can't be avoided (and performance/optimization is not a valid excuse).

lordfrito 3y ago
> The problem wasn't MISRA, but your management. Agreed. But it was my customers management. And the customer is always right yada yada. So instead of using MISRA to help produce a better deliverable, it gets used as cudgel, a blunt instrument with which to beat programmers with, to create metrics that show the managers are effective at managing. In these cases, code quality necessarily suffers as a result. Because your resource constrained team has to spend more and more time on busywork. In my mind, LINT is a better tool than MISRA, because all tools can and will be abused by management, but some tools are more easily abused than others.
- BeetleB 3y ago
  Why did your customer have access to your source code? Or was it the case that they didn't but they could access MISRA reports?
  - lordfrito 3y ago
    We were under contract to deliver them a working design, both hardware and software, which they would then manufacture. Basically outsourced R&D. So software was part of the deliverable. It was their product, their risk, after all. We didn't do this for long, just to pay the bills until we had our own products that were making us money.
    - 3y ago

glitchc 3y ago

Such a great story! Thank you for sharing.