Home > C++ > Pragmatically Feasible?

Pragmatically Feasible?

From the MISRA web site:

The Motor Industry Software Reliability Association (MISRA), is a collaboration between vehicle manufacturers, component suppliers and engineering consultancies which seeks to promote best practice in developing safety-related electronic systems in road vehicles and other embedded systems.

While browsing through the MISRA C++:2008 standard, I came across this not-unexpected requirement:

No Heap

I don’t know enough about the standard to know if it’s true, but I interpret this requirement as banning not only the use of “new/delete“, but also as banning the use of the dynamically managed STL container abstractions (vectors, lists, sets, maps, queues) and, hence, the many standard library algorithms that operate on them. I wonder what the MISRA Java specification, if there is one, says about dynamic memory allocation.

If my interpretation of 18-4-1 is correct, then the requirement can severely jack up the cost, schedule, and technical risks of any software component that is required to be compliant with the specification. For non-trivial applications requiring more than low-level, statically allocated arrays…..

Complexity is pushed out of the language and into the application code. The semantics of language features are far better specified than the typical application code. – Bjarne Stroustrup & Kevin Carroll

Because of the safety-critical nature of embedded automotive software, I can understand the reasoning behind the no-dynamic-memory-allocation requirement. But is it pragmatically feasible in today’s world; especially since software components keep getting larger and commensurately more complex over time? In other words, is it one of those requirements that doesn’t scale? Is it too Draconian?

For those C++ programmers who work in the automotive industry and happen to stumble upon this blog (which will probably be none), what has been your experience with this MISRA requirement and some of the other similarly unsettling requirements in the specification? Are “waivers” often asked for and granted? Is it an unspoken truth that people/companies pay public lip service to the requirement but privately don’t comply?


  1. dipper
    September 18, 2013 at 2:35 am

    Workaround: Reserve a big enough amount of memory on the stack, and use your custom allocators that make use of this space. And voilà! No more heap allocations, only dynamic stack memory allocations 🙂

  2. Anton
    September 18, 2013 at 2:55 am

    I do not know about automotive industry, but we worked on a project where we were not allowed to use dynamic memory allocation. That was high-performance face detection on multicore embedded system (http://www.adapteva.com/white-papers/face-detection-using-the-epiphany-multicore-processor/).

    At first the task seemed very complex. But we came to the following approach: in each core we statically allocated data structure, containing data fields for each part of the algorithm. There were fixed-size image part to process, small buffer (about 20 items) to store detected faces (if any), buffer to store classifier stages etc.

    So, I think automotive programmers do the same: they allocate some large “car state” structure, where everything is stored, and algorithm modifies parts of the structure. There is no need in dynamic containers: the car has fixed number of engine cylinders, fixed set of sensors and hardware to be controlled. Even the error buffer can store only fixed amount of last detected errors.

    • September 18, 2013 at 4:37 am

      Thanks for the input Anton. The only data structures you used were native arrays?

      • sukhinov
        September 18, 2013 at 4:54 am

        We used mix of struct and native arrays, statically allocated.

        We even manually configured linker-description-file (LDF) to say to the linker at which physical address each variable should be located.

      • September 18, 2013 at 4:58 am

        How big was/is the software?

  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: