Secure C ++ in mission-critical real-time applications

I would like to hear different opinions on how to use C ++ safely in mission-critical real-time applications.

More precisely, it is possible to create some macros / templates / class library for safe data processing (compaction for overflow, zerodivides creates infinity values ​​or division is possible only for special "non-zero" data types), arrays with associated validation and foreach loops, safe smart controllers (e.g. boost shared_ptr, for example) and even a secure multi-threaded / distributed model (message passing and lightweight processes like those defined in the Erlang language).

Then we prohibit some dangerous c / C ++ constructs, such as raw pointers, some raw types, our own β€œnew” operator, and native c / C ++ arrays (for the programmer, but not for the library, of course). Ideally, we should create a special preprocessor / controller, at least we should have some formal verification procedure that can be applied to sources using some kind of tool or manual for someone.

So my questions are:

1) Are there existing libraries / projects that use such an idea? (Embedded C ++ is apparently not desirable)?

2) Is this a good idea or not? Or can it be useful only for prototyping some other language? Or is it completely unsuitable?

3) Any other thoughts (or links) on this subject are also welcome.

Sorry if this question is not really a question, offtopic, duplicate, etc. but I did not find a more suitable place to ask him.

+7
c ++ embedded real-time
source share
3 answers

For the correct C ++ spelling rules for mission-critical real-time applications, see Joint Strike Fighter Coding Standards . Many of the rules are based on the MISRA C encoding rules , which I believe are proprietary. PC-Lint is a C ++ code test with sets of rules that you like (including MISRA rules). I believe that you can also set up your own rules.

+9
source share

We use C ++ in mission-critical real-time applications, although I believe that it is easy (theoretically) for us, because we should only provide real-time guarantees as well as the equipment used by our customers. Thus, sufficient profiling allows us to do without mlockall () or preload the stack or any other RT traditions. As for the language itself, I believe that everyday modern C ++ coding methods (those that obstruct the concepts of C) are completely sufficient to write reliable applications that can be used in RT contexts, given the equipment of the 21st century.

Unit tests and QA should be the main focus of efforts, not internal libraries, duplicating existing language functions.

+2
source share

If you write critical high-performance real-time S / W in C ++, you probably need every microsecond that you can get out of hardware. Thus, I would not offer all additional checks, such as those that you mentioned, at least those who have overhead consequences for the program. Obviously, you can mask floating point exceptions to prevent division by zero from a program crash.

Some observations:

  • A collaborative review of the entire code (possibly several reviewers). This will greatly improve quality without requiring many runtime checks.
  • Use non-release diagnostic and approval tools.
  • Use simulation systems to test on non-embedded hardware.
  • C ++ was specifically designed without such things as border checks for performance reasons.

In general, I do not propose arbitrarily restricting the language, although using RAII and smart pointers should have minimal overhead and provide a nice benefit.

Someone else pointed out that if you want Ada, just use Ada.

+2
source share

All Articles