"The input/output library <stdio.h> shall not be used."

Question

I'm reading the JSF AV C++ Coding Standards and the rule 22 says:

AV Rule 22 (MISRA Rule 124, Revised)

The input/output library <stdio.h> shall not be used.

Is there any reason to not use <stdio.h>?

I know that these rules are for C++ and we can use <iostream>... but what's wrong with <stdio.h>?

Answer 1

This JSF C++ standard is referencing MISRA-C:1998 and both are related to use of the C􏰀 language in safety critical systems. The latest standard, MISRA-C:2012 has been updated (providing more rationale and better examples), and MISRA Rule 124 is now Rule 21.6 "The Standard Library input/output functions shall not be used".

The rationale is pretty simple: streams and file I/O have unspecified, undefined and implementation-defined behaviours associated with them. Also included in the guideline are the references to the C standards (C90 and C99) sections where these unpredictable behaviors are described.

The rule can be broken (through a deviation process) if the actual implementation is well defined or the code is shown not to be critical.

Answer 2

Every now and then, there are questions like this, about why some coding standard mandates this or that.

The correct answer should always be: Whatever the authors of that coding standard intended. Sometimes, a coding standard gives reasons for its rules; this one apparently does not. Therefore, we can only guess what the answer to your question might be.

I'll thus add my own guess:

Air vehicles sounds like really serious business, with extremely high correctness and robustness requirements. printf, scanf et al make it easy to write code which happily passes the compiler but creates undefined behaviour at run time.

Those C functions do have one advantage to normal C++ streams: format strings make it easier to write internationalised code. Consider this quickly made-up example using an std::ostream for some UI component such as a button label in a customer management application:

os << "Update customer\n";

You might want to dynamically add the customer's name:

os << "Update " << customer_name << "\n";

And you might want to dynamically insert the foreign-language word for "Update":

os << InternationalString(id_update) << " " << customer_name << "\n";

However, this is inherently English-centric. It will product correct English strings like "Update John" or "Update Joe", but will e.g. fail for German, which has different grammar and requires strings like "John aktualisieren" or "Joe aktualisieren", with the name in front of the verb in this case.

This is where format strings shine:

sprintf(s, FormatString(id_update_customer), customer_name);

Depending on the application's language setting, such a FormatString function may return "Update %s" or "%s aktualisieren".

Still, it's very dangerous. As a matter of fact, if customer_name in my example above was a std::string, you'd have undefined behaviour already.

Libraries like Boost.Format try to combine the flexibility of format strings with the type safety of streams.

Going back to your actual question, my guess is that flexibility with regards to international strings is not a great concern in the air-vehicles business.

---

As you can see, every aspect of a coding standard can be discussed at great length. The reasons for individual rules may not always be so apparent, and they will often have something to do with the application domain for which the standard was written.

If you cannot ask the author of the coding standard, then your question cannot really be answered.

Answer 3

The most obvious problem would be the lack of type safety in printf, scanf, and their various cousins (e.g., sprintf).

Along with the type safety problems, the scanf and sprintf families make it fairly difficult to ensure against buffer overruns. It can be done, but it's not trivial, and it would appear that only a tiny minority of C programmers have any clue of how to handle these kinds of tasks at all.