4 ms·

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 j

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.
    - BeetleB 3y ago
      Makes sense. The approach would then be to inform them that "We'll comply with MISRA, but you'll get poor code quality." It's their choice. Put yourself in their shoes. As they're not doing the coding, it's riskier for them to sit with you and understand the code and all the exceptions you made to MISRA.
      - lordfrito 3y ago
        > The approach would then be to inform them that "We'll comply with MISRA, but you'll get poor code quality. Which we did. > Put yourself in their shoes. Oh, I get it. I understand where they were coming from. My complaint isn't with the customer, its with MISRA being a poor tool and ripe for this kind of abuse. Because my customer needed to point to something, they point to MISRA, not understanding this isn't entirely helping them. I loath tools that can be abused this way. Dumbs everyone in the room down. Next you get experts in MISRA that waste everyone's time talking about how wonderful it is. I'm all for scrutinizing code, but don't waste my time scrutinizing code needlessly.
        BeetleB 3y ago
        > My complaint isn't with the customer, its with MISRA being a poor tool and ripe for this kind of abuse. Any guideline/linter is ripe for abuse. I don't see MISRA being an outlier in this regard. Had everything been developed in house, MISRA wouldn't have been the bottleneck. You'd ignore whatever MISRA rules are not relevant, and note the exception down formally, and be done with it. My job in that company was primarily to understand the automotive ISO guidelines, and inform the team about what was OK and what wasn't, and to write those rationales for the auditor(s). As an extreme example, for one component, the ISO standard allowed us to ignore almost all the guidelines because if it has been tested heavily, it suffices as evidence the component is safe. For that component, we felt it cheaper to test the heck out of it than to conform to the guidelines. We tested it by running it continuously for months, feeding in random inputs. Cheaper to have a computer do it than highly paid engineers getting bogged down. Even in a contracting scenario, this could have been avoided. You'd write your exceptions, and the customer would get an auditor to go over your exceptions, and be done with it. Don't blame guidelines for poor organizational behaviors. As I said elsewhere, the ISO guidelines allow you to be sane about it. Think of the plus side, though. If you had gone the route you wanted, you would have to read several hundred pages of an ISO standard multiple times before you could be well versed enough to know when it's OK to violate the guidelines. Reading those documents is a lot worse than following MISRA ;-)
DaiPlusPlus 3y ago
> No dynamic allocation unless it can't be avoided (and performance/optimization is not a valid excuse). Eliminating dynamic allocation is a performance optimisation, I’d have thought?
- dwattttt 3y ago
  Not if it precludes using a more efficient algorithm/mechanism vs the hoops you'd have to jump through to get something functional without it
- trealira 3y ago
  Sometimes, if your computer has memory to spare, allocating more memory will make the program faster. For example, I've read a paper that found that, for a compiler written in C, allocating tree nodes using arenas and deallocating arenas all at once sped up the program at the cost of more memory usage (compared to maintaining a free list). Allocation was quicker because it was usually just a pointer bump, not navigating a linked list, and deallocation was quicker because the arena chunk was marked as free, not individual nodes. I imagine it would be similar with eliminating dynamic allocation vs having it. For example, I assume it would be more performant for an implementation of printf to dynamically allocate space for its result and write a whole line to stdout at once than to, for instance, make a system call to write each byte to stdout while avoiding dynamic allocation. I can't think of any better examples for a bare metal context at the moment, though.
- shiroiuma 3y ago
  No. Eliminating dynamic allocation is to make the program deterministic. The whole point of standards like MISRA or DO-134(b) (for aviation) are to make software deterministic and predictable, not to make them fast. On embedded systems like this, they usually do things like disabling on-chip caches because those are non-deterministic; this of course kills performance, but it doesn't matter.

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.
  - BeetleB 3y ago
    Makes sense. The approach would then be to inform them that "We'll comply with MISRA, but you'll get poor code quality." It's their choice. Put yourself in their shoes. As they're not doing the coding, it's riskier for them to sit with you and understand the code and all the exceptions you made to MISRA.
    - lordfrito 3y ago
      > The approach would then be to inform them that "We'll comply with MISRA, but you'll get poor code quality. Which we did. > Put yourself in their shoes. Oh, I get it. I understand where they were coming from. My complaint isn't with the customer, its with MISRA being a poor tool and ripe for this kind of abuse. Because my customer needed to point to something, they point to MISRA, not understanding this isn't entirely helping them. I loath tools that can be abused this way. Dumbs everyone in the room down. Next you get experts in MISRA that waste everyone's time talking about how wonderful it is. I'm all for scrutinizing code, but don't waste my time scrutinizing code needlessly.
      - BeetleB 3y ago
        > My complaint isn't with the customer, its with MISRA being a poor tool and ripe for this kind of abuse. Any guideline/linter is ripe for abuse. I don't see MISRA being an outlier in this regard. Had everything been developed in house, MISRA wouldn't have been the bottleneck. You'd ignore whatever MISRA rules are not relevant, and note the exception down formally, and be done with it. My job in that company was primarily to understand the automotive ISO guidelines, and inform the team about what was OK and what wasn't, and to write those rationales for the auditor(s). As an extreme example, for one component, the ISO standard allowed us to ignore almost all the guidelines because if it has been tested heavily, it suffices as evidence the component is safe. For that component, we felt it cheaper to test the heck out of it than to conform to the guidelines. We tested it by running it continuously for months, feeding in random inputs. Cheaper to have a computer do it than highly paid engineers getting bogged down. Even in a contracting scenario, this could have been avoided. You'd write your exceptions, and the customer would get an auditor to go over your exceptions, and be done with it. Don't blame guidelines for poor organizational behaviors. As I said elsewhere, the ISO guidelines allow you to be sane about it. Think of the plus side, though. If you had gone the route you wanted, you would have to read several hundred pages of an ISO standard multiple times before you could be well versed enough to know when it's OK to violate the guidelines. Reading those documents is a lot worse than following MISRA ;-)

DaiPlusPlus 3y ago

> No dynamic allocation unless it can't be avoided (and performance/optimization is not a valid excuse). Eliminating dynamic allocation is a performance optimisation, I’d have thought?

dwattttt 3y ago
Not if it precludes using a more efficient algorithm/mechanism vs the hoops you'd have to jump through to get something functional without it
trealira 3y ago
Sometimes, if your computer has memory to spare, allocating more memory will make the program faster. For example, I've read a paper that found that, for a compiler written in C, allocating tree nodes using arenas and deallocating arenas all at once sped up the program at the cost of more memory usage (compared to maintaining a free list). Allocation was quicker because it was usually just a pointer bump, not navigating a linked list, and deallocation was quicker because the arena chunk was marked as free, not individual nodes. I imagine it would be similar with eliminating dynamic allocation vs having it. For example, I assume it would be more performant for an implementation of printf to dynamically allocate space for its result and write a whole line to stdout at once than to, for instance, make a system call to write each byte to stdout while avoiding dynamic allocation. I can't think of any better examples for a bare metal context at the moment, though.
shiroiuma 3y ago
No. Eliminating dynamic allocation is to make the program deterministic. The whole point of standards like MISRA or DO-134(b) (for aviation) are to make software deterministic and predictable, not to make them fast. On embedded systems like this, they usually do things like disabling on-chip caches because those are non-deterministic; this of course kills performance, but it doesn't matter.