[HN Gopher] Misra C++:2023
___________________________________________________________________
Misra C++:2023
Author : ksec
Score : 93 points
Date : 2023-12-17 16:52 UTC (6 hours ago)
(HTM) web link (forum.misra.org.uk)
(TXT) w3m dump (forum.misra.org.uk)
| convery wrote:
| Direct link: https://misra.org.uk/product/misra-cpp2023/
| mgaunard wrote:
| It's 15 pounds.
|
| Can someone give the gist of it?
| ska wrote:
| It's a standard for the use of c++ in critical systems.
| Basically a guide to techniques and language features you can
| and can't use (or how) and still have very
| predictable/controllable system behavior.
| 1MachineElf wrote:
| I recently watched this webinar[0] about it, presented by the
| company ParaSoft, which develops a static analysis tool and
| compliance reporting solution for businesses required to use
| MISRA C++[1].
|
| [0] https://www.brighttalk.com/webcast/18694/602198
|
| [1] bhttps://www.parasoft.com/white-paper/buyers-guide-static-
| cod...
| josefx wrote:
| At least the wiki article on MISRA C cites multiple studies
| that consider the rules mostly pointless, in some cases
| outright counterproductive and basically accuses it of being
| only beneficial to companies selling compliance tools. If
| MISCRA C++ is anywhere as bad you might be better of avoiding
| it.
| almostnormal wrote:
| With strict rules anyone can write software that does not
| instantly fail horribly (e.g., if pointers are not allowed,
| there won't be a bad dereference (but that's not even in
| misra)). That helps outsourcing to the lowest bidder.
| sam_bristow wrote:
| You can get a reasonable flavour of thw type of rules by
| looking at the Autosar C++ standard.
|
| MISRA C++ 2023 is a massive improvement over the previous
| (2008) version.
| FirmwareBurner wrote:
| Great royalty free alterative to MISRA C: [1] Embedded System
| development Coding Reference guide - Software Reliability
| Enhancement Center, JAPAN
|
| [1] https://www.ipa.go.jp/publish/qv6pgp00000011mh-
| att/000065271...
| ska wrote:
| Not super helpful for c++.
|
| Note the previous MISRA std. predates "modern" c++, as do some
| others.
| FirmwareBurner wrote:
| Ah, my bad, I misread the titles as being MIRA C, not C++.
| pjmlp wrote:
| Additionally this is the update for C++17.
| Longhanks wrote:
| ...which has been surpassed by two ISO standards already,
| with the third one on the road.
| lichtenberger wrote:
| At least they are already discussing the next version.
| ska wrote:
| That's not really a big deal in this context. Getting
| over the 2011 change was a big jump, and basically makes
| modern c++ usable for many more projects.
|
| Lots of toolchains are pretty conservative also, 2017 is
| pretty new there. And much like the ISO standard, updates
| should be a lot easier now.
| pjmlp wrote:
| You will hardly find a C++ compiler that is 100% C++17
| compliant, lesser so with those later standards.
|
| Currently all C++ implementations are lagging behind ISO,
| as all major commercial contributors focus in other
| stacks, and take C++14 / C++17 as good enough for their
| in-house use of C++.
|
| The bigger three have lost steam, while everyone else is
| even further behind .
| tambre wrote:
| Is there anything that GCC is missing? Looks complete to
| me [0]. Everything besides modules is also there for
| C++20 [1]. I'm at an automotive startup and we've been
| using a few C++26 features since summer already.
|
| [0] https://en.cppreference.com/w/cpp/compiler_support/17
| [0] https://en.cppreference.com/w/cpp/compiler_support/20
| pjmlp wrote:
| Last time I tried C++17 parallel STL algorithms, I wasn't
| so lucky.
|
| Then there is the whole issue that many libraries authors
| cannot set in stone just one compiler / OS.
| zamadatix wrote:
| This metric isn't really useful. This disregards any
| value of say a compiler implementing 99% of all features
| ever announced, including draft C++26 features, because
| it's missing a single C++17 feature preventing it from
| saying it's fully compliant so we shouldn't bother
| reading about anything but old stuff.
|
| The big 3 already support features from C++23 worth
| learning about
| https://en.cppreference.com/w/cpp/compiler_support
| Obviously you can't always use that, but most places with
| a C++ compiler today support at least some useful
| features past C++17.
| pjmlp wrote:
| It is clearly useful, as it makes impossible to write
| portable code, across compilers and operating systems.
| bluGill wrote:
| Most of what is missing is esoteric features that you
| propable wouldn't use use. So the code is portable anyway
| pjmlp wrote:
| It is clearly useful, as it makes impossible to write
| portable code, across compilers and operating systems.
|
| This kind of landmines is what keeps many code bases
| still using C++11 and C89.
| f1shy wrote:
| I don't care what the Standard says. I care about what my
| compiler can do.
| ykonstant wrote:
| Thank you very much for this resource.
| xjia wrote:
| If you are interested in this, take a look at NaiveSystems
| Analyze [0] which is a free and open source static analyzer for
| checking MISRA compliance etc.
|
| Disclaimer: I'm the founder.
|
| It has been battle tested with real customers in automotive,
| medical devices, and semiconductors. AFAIK this is the first FOSS
| tool that achieves commercial use standards (extensive ruleset
| coverage, low false positives based symbolic execution (which
| Coverity relies heavily on) and SMT solver, ...)
|
| [0]: https://github.com/naivesystems/analyze
| ska wrote:
| It doesn't support this version yet, right?
| xjia wrote:
| 2023 is supported in the enterprise edition but not in the
| community edition yet. We gradually move features from EE to
| CE as new features added to EE. So you can expect 2023
| support in CE in the future :-)
| ska wrote:
| Good stuff!
| vodou wrote:
| One thing that surprised me a bit was that exceptions are more or
| less recommended in these guidelines. In the section "4.18
| Exception handling", it is mentioned that "most compilers provide
| options (such as -fno-exceptions) that can be used to disable
| exceptions in order to eliminate the code and size overheads".
| Then it goes on describing how this makes it impossible to comply
| with a bunch of other rules.
|
| Since these are "guidelines for the use of C++17 in critical
| systems", I would have expected it to prohibit exceptions due to
| their non-determinstic nature. On a side note, dynamic memory is
| prohibited (rule 21.6.1).
|
| I haven't read the earlier MISRA C++ guidelines so I don't know
| if this have changed.
| otabdeveloper4 wrote:
| Prohibiting exceptions is a toxic antipattern. Once you have
| more than one thread you want to propagate fatal errors in a
| sane way. ("Just crash the whole program, #yolo" is not a sane
| way.)
| shadowgovt wrote:
| It depends on the problem domain. For automotive embedded
| software? Definitely not. But Google, for instance, bans them
| in much of its server code under the principle that
| exceptions should denote circumstances where the entire
| program cannot recover and when a server node cannot recover,
| logging noisily and failing fast so that it can be restarted
| into a working state is preferable to trying to unwind a bad
| state.
|
| Given that constraint, they conclude that the overhead of
| maintaining exception unwinding and the non-local control
| flow aren't worth it.
| cpgxiii wrote:
| The classic GSG prohibition on exceptions has more to do
| with a lack of exception safety in their legacy code base
| than anything else. Promptly-crash-on-failure can be
| achieved by adopting a "don't catch exceptions" style, with
| significant advantages of not throwing away much of the
| strengths of RAII or needing the evil hack that is two-
| phase initialization.
| shadowgovt wrote:
| You can for all intents and purposes avoid two phase init
| with factory functions (which is how Go does it) and
| private constructors.
|
| (To my memory though, Google didn't throw away the
| benefits of RAII without allowing exceptions... They
| discouraged complicated behavior in constructors and so
| the only thing a constructor could fail on was OME, which
| was supposed to crash anyway).
| GuB-42 wrote:
| "just crash the whole program" is much more sane than to
| attempt to handle unrecoverable errors.
|
| Almost all systems to which MISRA apply have watchdogs, and
| crashing to let the watchdog restart the program is a common
| pattern.
| AlotOfReading wrote:
| There are cases in MISRA's problem domain where the
| software watchdog is part of the same program, and fully
| crashing that program is a different, more severe error
| than alternatives.
| Espressosaurus wrote:
| Prohibiting exceptions is necessary in the embedded space
| for, err, space and allocation reasons.
|
| Just crash the system and reboot the MCU can make sense
| depending on the application. And where it can't, you need to
| take the same kind of care for handling every single problem
| at the call site, or correctly propagating it to a layer that
| can handle it.
|
| Exceptions aren't special here, they are simply _a_ way to do
| error handling and recovery.
|
| It's the kind of rule that doesn't make sense for
| applications, but when you've got tightly constrained memory
| limits, it makes sense.
| mgaunard wrote:
| Exceptions don't generate more space outside of code where
| you use try/catch, which is generally viewed as an anti-
| pattern.
| jandrewrogers wrote:
| Exceptions are not a sane way to handle many error conditions
| either. Predictably and efficiently handling fatal error
| conditions will require custom handling code regardless. For
| many types of software, the downsides of exceptions are not
| offset by a corresponding benefit in real reliable systems.
| I've worked on systems that work both ways and I have a hard
| time recommending exception use.
| mmoll wrote:
| On the other hand, once your embedded system is
| sufficiently large, people will want to use (and inevitably
| will use at some point) standard containers such as
| std::string or std::vector. And without exceptions, all of
| those might invoke UB at any time (I have yet to see a
| standard library that understands and honors -fno-
| exceptions; usually they just drop all try-catch blocks and
| all throws)
| TwentyPosts wrote:
| Could you elaborate on that? I'd love to see an example
| of this. Are you saying that even relatively simple code
| (using eg. std::vector) could easily cause UB if -fno-
| exceptions is enabled?
| accelbred wrote:
| Any exception thrown with -fno-exceptions results in
| std::terminate. The behavior of std::terminate is
| unspecified.
| Karellen wrote:
| The behaviour is unspecified by the standard.
|
| Your compiler vendor has to pick a (reasonable) behaviour
| though and apply it consistently, and while they are not
| required to document it (IIRC - I think that's just for
| implementation-defined?) you can probably get them to
| tell you if you have a good support relationship with
| them. Or you can just figure out what the compiler does,
| and hope they don't change the behaviour too much with
| the next release :-)
| mmoll wrote:
| Most standard containers have no way to communicate
| allocation failure to the caller in the absence of
| exceptions (think of constructors that take a size).
| Worse, the implementations I've seen would eventually
| call operator new, assuming it would throw if it fails.
| That is, subsequent code would happily start copying data
| to the newly created buffer, without any further tests if
| that buffer is valid. In the absence of exceptions, that
| won't work.
| TwentyPosts wrote:
| I guess my hope was that the program would just terminate
| immediately the instant it tries to throw an exception
| while -fno-exceptions is set, thus ideally preventing any
| further action from the program.
| tsimionescu wrote:
| Well, what do you expect std::vector<T>::at() to do if
| the index is out of bounds and it can't throw exceptions?
| Or std::vector<T>::push_back() if it can't reallocate to
| a larger size?
|
| These are just some obvious cases. Not to mention that
| any use of operator new is UB if memory allocation fails
| and the system can't throw exceptions.
| TwentyPosts wrote:
| Well, my hope was that we'd have a guarantee that the
| program is in fact just going to terminate, and the
| process is going to die.
|
| That's probably not great and might leave data in a bad
| shape, but it seems better than "undefined behavior" aka
| no guarantees whatsoever, no?
| oytis wrote:
| In safety critical embedded systems there is no such
| thing as "program just terminating". The program is the
| only software that is running on your device, and you
| need to degrade execution to some safe state no matter
| what. Every error should be processed, ideally right
| where it occurred (so I am not a great fan of exceptions
| either).
| andrepd wrote:
| Exactly. So you don't want `at()` either, you want a sane
| interface that would return an Option<T> for you to
| handle as you wish.
| nextaccountic wrote:
| C++23 has std::expected, right?
| captainmuon wrote:
| Exceptions are not non-deterministic, although the control flow
| can be a bit non obvious of course.
|
| I think if you disallow exceptions you run into other problems.
| How can a constructor fail now? You need to have some kind of
| flag showing if an object is fully constructed. But then that
| goes against the idea to "make illegal states unrepresentable".
|
| I do wish C++ had more tools to reign in exceptions. Maybe an
| "onlythrows X" annotation that says only these very specific
| exceptions may escape from a block, and the checker will
| complain if it cannot prove that only X can be thrown. The
| opposite of checked exceptions basically.
| jupp0r wrote:
| The constructor error problem is easily solved by using
| factory functions and two phase construction. The problem is
| that the standard library is relying on exceptions quite a
| bit and major parts become unusable.
| lelanthran wrote:
| For what definition of "easy"?
|
| Simply passing by value can result in a constructor that
| fails, while still bypassing any of the factory functions.
| jupp0r wrote:
| Easy as in "competent C++ programmers do this every day"?
|
| If the copy constructor can fail and you don't want that,
| then delete it?
| kwant_kiddo wrote:
| it is easy? It is the named constructor idiom.
|
| I don't understand why jupp0r is getting downvoted?
|
| Most big public c++ projects turn off exceptions, so it
| seems to be the norm more than anything.
| gpderetta wrote:
| Because two phase construction is a widely disliked
| idiom. Named constructors retuning optional objects are
| tolerable though.
| jupp0r wrote:
| Two phase construction isn't widely disliked, it's
| completely fine if it's used as an implementation detail
| of a factory.
| jandrewrogers wrote:
| Handling constructor failure is one of the least valuable use
| cases for exceptions. Idioms for exception-free construction
| are straightforward and some cases will require these idioms
| even with exceptions.
|
| Resource exhaustion or hardware failures are the more
| straightforward use cases for exceptions, but doing anything
| clever in those cases requires writing similar handling code
| as you would without exceptions.
| oytis wrote:
| In the domain where Misra is applied, resource exhaustion
| and hardware failures are totally valid scenarios that need
| to be processed in the same way as any other error.
| mgaunard wrote:
| It's actually the most useful one. It enables the creation
| of state invariants.
| iaseiadit wrote:
| For those unfamiliar, these are standards published by the Motor
| Industry Software Reliability Association (MISRA) that provide
| guidelines for C++ and aim to promote safety, security, and
| reliability in embedded system software.
| zengid wrote:
| Confusing that they don't keep their name in line with the C++
| version: MISRA C++:2023 Guidelines for the use
| C++:17 in critical systems
| jes wrote:
| Can you say how your tool compares to Vector PC-Lint in terms of
| analyzing compliance w/r/t MISRA C and C++?
| Longhanks wrote:
| Ah yes, the motor industry, which with the exception of Tesla
| delivers some of the world's most miserable, buggy, unpleasant-
| to-use infotainment software, crippled by bureaucracy, introduces
| more of the latter in order to micromanage software developers
| even more.
|
| Thanks, but no, thanks. I'd rather you completely stop developing
| software and just let me plug in my phone. The less software my
| car runs, the safer I feel, and I need nothing more but
| navigation and music, which my phone handles just fine.
| coumbaya wrote:
| In general you would apply MISRA only on some critical parts of
| the software, and the infotainment wouldn't be part of this. At
| least it was like this when I applied MISRA on high speed
| trains, and when I worked briefly at the company that invented
| the airbag, their infotainment box was a windows embedded with
| 0 SIL2+ software on it. (But I agree with your point tho).
| nanolith wrote:
| MISRA isn't typically used in infotainment systems.
|
| It's used in safety critical systems, like the car computer,
| which manages the monitoring and adjustment of fuel to oxygen
| mixture in the engine.
| rightbyte wrote:
| Misra rules are not what is wrong with automotive software
| development. I would say it is like 99% a wage problem.
| SV_BubbleTime wrote:
| I'm much closer to this.
|
| A few issues...
|
| - Most people have no idea how many modules there are in
| their vehicles. It's a LOT more code than you realize.
|
| - Companies like ERAS, Vector, Kvaser, Mentor, Bosch, and
| others have a great lock on software for systems they steer
| via SAE and ISO.
|
| - AutoSar and other shitty systems. It doesn't matter how
| good your programmers are if they are kneecapped out the
| gate.
|
| - Same as any programming lately at big companies... it's 10
| managers to every actual programmer.
|
| - Outsourced. When I was at a Chrysler, code was worked on,
| released, and tested locally for some modules. Now... often
| times no one at Chrysler may even be allowed to see code. A
| LOT of work is done in India.
|
| MISRA isn't even close to a problem in automotive. And I
| disagree it's a wage problem. You could pay the engineers in
| India more, and it still wouldn't give them any idea how the
| consumer will use the end product. It doesn't help them
| understand repair/replace diagnostics. No one is monitoring
| the ever increasing complexity of the systems as a whole.
|
| Overall, cars do work well. But damn if they aren't trying to
| ruin that.
| aaronmdjones wrote:
| Your car is running a hell of a lot more software than what
| you've just described. The ECU manages the engine; the BCM
| manages lights, wipers, airbags, and seatbelt pre-tensioners;
| you'll also have ABS (anti-lock brakes, so you can steer while
| braking instead of plowing straight ahead regardless of the
| orientation of your wheels) and either Traction Control or
| Electronic Stability Control. Every single one of these things
| is safety-critical, whose failure could cause a crash before
| you can react to it. It's this software that's written to the
| MISRA standards.
| krater23 wrote:
| You would wonder how much software of parts in your Tesla is
| written by this big bad german car suppliers that all work
| under the MISRA rules. Would the critical software things of a
| Tesla be written by Tesla with their quality understanding,
| then this cars would be just death traps.
| hgs3 wrote:
| I conformed to MISRA C:2012 for an open source project and what's
| unfortunate is the lack of open source static analyzers for
| verifying MISRA compliance. Aside from Cppcheck [1] all other
| analyzers I found are commercial/proprietary. It's surprising
| because Clang should make writing an analyzer easier than ever.
|
| [1] https://cppcheck.sourceforge.io/misra.php
| xjia wrote:
| Clang has its own limitations. And it takes more effort than
| just writing the checkers. We open sourced our previously
| proprietary static analyzer (mostly based on Clang but also
| integrated other useful tools) but the commercial/enterprise
| edition still has its own value in stability, quality
| assurance, and technical support. It's more like building a
| Linux distro (e.g. RHEL) from various FOSS components.
| josephcsible wrote:
| Isn't the most likely reason that no FOSS tools support it that
| it's not an open standard?
| superfist wrote:
| Each C/C++ guideline define language subset so de facto new
| language but with weak enforcement where in practice most
| organisations following it anyway create some specific exceptions
| from that guidelines. C/C++ world (C less) is a mess, it can't be
| fixed and this agony will be very long lasting.
| andrepd wrote:
| Indeed. I don't want to be a shill but "safe C++" has a name,
| it's called Rust. C++ is such an incredibly complex language
| filled with such easy to set off footguns, that there is no way
| out of this mess without a non-backwards complete solution,
| like Rust.
| pelorat wrote:
| I love C++ but it shouldn't need guidelines :(
| parlortricks wrote:
| I am a C (not C++ hobbyist), and I try to read up on standards
| and style guides to understand what I should be trying to do.
| Given that Misra has a C:2012, does anyone know how this compares
| to SEI Cert C Coding Standard (which im reading right now along
| with Secure Coding in C and C++)?
___________________________________________________________________
(page generated 2023-12-17 23:00 UTC)