Safer C++ with MISRA-C++-2023 - Peter Sommerlad - ACCU 2024
Вставка
- Опубліковано 7 вер 2024
- ACCU Membership: tinyurl.com/yd...
---
Safer C++ with MISRA-C++-2023 - Peter Sommerlad - ACCU 2024
---
MISRA guidelines and corresponding static analysis tooling exist to foster programming practices that are considered important for safety-critical systems, especially in the automotive industry.
In application areas where human lives or capital is at risk, safe and secure code is a must, but even in other domains the internal quality of C++ programs is an important factor for programmers' effectiveness. Adhering to MISRA-C++ can help to achieve better internal quality, reducing the risk of undefined behavior and portability issues through implementation-defined behavior.
Since the original MISRA-C++:2008 guidelines that addressed C++03, five new C++ standards were released. While inherently conservative, an update to the MISRA-C++ guidelines was prepared and is released in 2023 addressing C++17.
This talk will give an overview of why and what MISRA-C++:2023 attempts to achieve as well as demonstrate some example MISRA-C++ rules and how modern C++ design already fulfills them.
Some seemingly surprising guidelines are shown and explained, why such "unachievable" guidelines exist and the rationale behind those guidelines that one seemingly must violate.
For example, an advisory guideline forbids to write your own loops, except for a few cases, which sounds ridiculous on first sight. The talk will show a few cases how to work around but also tells you not to sweat it to hard, but reminds you that getting loop statements correct is really hard.
Slides: accu.org/conf-...
Sponsored By think-cell
---
Peter Sommerlad
Peter Sommerlad is a consultant and trainer for Safe Modern C++ and Agile Software Engineering.
Peter Sommerlad is a consultant and trainer for Safe Modern C++ and Agile Software Engineering. Peter was professor at and director of IFS Institute for Software at FHO/HSR Rapperswil, Switzerland until February 2020. Peter is co-author of POSA Vol.1 and Security Patterns. He inspired the C++ IDE Cevelop with a unique C++ feedback, refactoring, and code modernization experience. Peter is a member of MISRA-C++, Hillside, ACM, IEEE Computer Society, ACCU, ISO WG23 and the ISO WG21 C++ committee.
---
The ACCU Conference is the annual conference of the ACCU membership, but is open to any and all who wish to attend. The tagline for the ACCU is 'Professionalism in Programming', which captures the whole spectrum of programming languages, tools, techniques and processes involved in advancing our craft. While there remains a core of C and C++ - with many members participating in respective ISO standards bodies - the conference, like the organisation, embraces other language ecosystems and you should expect to see sessions on C#, D, F#, Go, Javascript, Haskell, Java, Kotlin, Lisp, Python, Ruby, Rust, Swift and more.The ACCU Conference is a conference by programmers for programmers about programming.
Discounted rates for members.
ACCU Membership: tinyurl.com/yd...
2024 Program: accu.org/conf-...
accu.org
www.accuconfer...
mastodon.socia...
/ accu-conference
bsky.app/profi...
/ accuorg
/ accuconf
---
UA-cam Videos Filmed, Edited & Optimised by Digital Medium: events.digital...
#accuconf #programming #cplusplus #cppprogramming #automotive
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.