Home

MISRA C++:2008

Probably worth noting MISRA-C++. Not much to go on since you have to pay for the document that outlines the standards.

MISRA C++:2008 was finally released on June 5, 2008, following 3 years of work by a group of willing volunteers. They set out to craft a set of rules for the safe use of C++ in critical systems...

It seems not so long ago that the insurrection to fork a safer subset of C++ in Europe was suppressed. Instead of redefining the language, the efforts are now on trying to enforce coding standards and best practices. Try to solve things on the engineering side, rather than the programming language specification side.

By Chris Rathman at 2008-09-26 20:03 | Software Engineering | other blogs | 14965 reads

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Regarding MISRA

I am inclined to agree with the long-running and well-articulated views of Peter Amey. MISRA C, being unenforceable, is merely a ``feel good.'' effort. My own assessment of the MISRA C rules is that some of them actually preclude certain good practices, and the number of ``exceptions'' used in real projects suggest that the MISRA rules are, at best a starting point for forming a project-specific guideline rather than any serious basis for assurance. I don't mean to minimize the value of having a starting point, but let's not make it into something it is not.

MISRA C++ sustains the tradition of MISRA C. Sometimes tradition isn't all it is cracked up to be.

By shap at Sun, 2008-09-28 16:19 | login or register to post comments

Is there a useable, safe, verifiable subset of C++?

By "useable" I mean suitable for writing real-world programs with reasonable expressiveness. By "safe" I mean free of memory errors/undefined behavior. By "verifiable" I mean that a program's compliance with the rules can be statically verified, either within the language or via an external tool. Admonitions to "don't do that" aren't good enough, unless something can prevent you from "doing that".

The trivial answer to the question is "yes"--write an interpreter for some other language in C++. :)

Beyond that, I suspect probably not. To make C++ safe, you would have to:

1) solve the problem of memory deletion errors--either add a GC, or constrain the heap in some other fashion.
2) abolish unsafe casts (raw C casts and reinterpret_cast) and unions.
3) abolish pointer arithmetic.
4) abolish taking the address of stack-based objects.

By Scott Johnson at Mon, 2008-09-29 17:46 | login or register to post comments

5) abolish non-const subtyping

5) abolish non-const pointer subtyping (and enforce const, i.e. remove const_cast etc)

By Andreas Rossberg at Mon, 2008-09-29 18:33 | login or register to post comments

6) Fix multiple inheritance

Right now its still too easy to do reasonable-looking casts on a poorly designed MI hierarchy and get a wild pointer.

By Scott Johnson at Mon, 2008-09-29 23:21 | login or register to post comments

7) Disallow uninitialised

7) Disallow uninitialised automatic variables

By Mattias Engdeg at Tue, 2008-09-30 13:04 | login or register to post comments

8) Get rid of memcpy(), memmove(), memset(), etc.

or at least constrain them to memory pools that can be proven to not contain pointers.

9) Replace the array/pointer dichotomy with true arrays--i.e. move vector from a library component to a base language component.

10) Speaking of vector, split it into two different array-ish types. One which is of fixed or bounded size, and never needs to move; the other which can grow without bound (relocating the storage if necessary) but provides sufficient indirection in the iterator implementation that existing iterators are not invalidated. (Right now if you have an iterator pointing to a vector and expand the vector such that it needs to find a new place to live--existing iterators become wild pointers).

I'm sure another 10 could be listed, and already we're at a language which no longer resembles C++...

By Scott Johnson at Tue, 2008-09-30 17:05 | login or register to post comments

"a language which no longer resembles C++"

sounds nice! ;-)

By raould at Wed, 2008-10-01 22:19 | login or register to post comments