I just dislike how MISRA and SPECTRE have become things that coders need to think about. Especially because they're problems that aren't caused by the language, but by hardware manufacturers. Overflows before being added to wider types and speculative execution etc. Hardware advances, with little concern about the problems it creates further down the line. I'm not a MISRA hater, but meh...
MISRA is a set of very exhaustive rules, which are primary intended for software products, which MUST implement them. E.g. Automotive, chemical, power plants. These systems require this level of care with every piece of the system due to human lives being in danger. These systems are also generally much more expensive than most software products. If your job is to develop a CRUD application with extra features, this ruleset is probably overkill and you will quickly exceed the budget for such a tool. Technically, you'd also need somebody separately trained to check and verify the hardware for exploits like Spectre (or disabling any kind of perfomance boosts and hyperthreading...). I don't see how you'd be responsible for SPECTRE exploits on a customers hardware, since you usually have no way of defining Specs/maintaining/patching hardware components for 95% of software products. This is the job of the On-Site operators and the customer in general. My "qualification": Working with MISRA for years in SW development, where compliance is required by contract.
int x, y; then x/0 and x/y has implementation defined % of UB.
I just dislike how MISRA and SPECTRE have become things that coders need to think about. Especially because they're problems that aren't caused by the language, but by hardware manufacturers. Overflows before being added to wider types and speculative execution etc.
Hardware advances, with little concern about the problems it creates further down the line.
I'm not a MISRA hater, but meh...
MISRA is a set of very exhaustive rules, which are primary intended for software products, which MUST implement them.
E.g. Automotive, chemical, power plants. These systems require this level of care with every piece of the system due to human lives being in danger.
These systems are also generally much more expensive than most software products.
If your job is to develop a CRUD application with extra features, this ruleset is probably overkill and you will quickly exceed the budget for such a tool.
Technically, you'd also need somebody separately trained to check and verify the hardware for exploits like Spectre (or disabling any kind of perfomance boosts and hyperthreading...).
I don't see how you'd be responsible for SPECTRE exploits on a customers hardware, since you usually have no way of defining Specs/maintaining/patching hardware components for 95% of software products. This is the job of the On-Site operators and the customer in general.
My "qualification": Working with MISRA for years in SW development, where compliance is required by contract.