MISRA Discussion Forums

Full Version: Dir 4.7 Unclear exactly what the critera is?
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
What does it mean to be "tested in a meaningful manner"?

Is there any requirement on what is done once tested? For example, if there is no corrective action is it sufficient to just log the error?

Does returning the error to the caller qualify? In an API, the implementation of a API function may call subsequent functions that return an error. If only one such function is called then the only thing to do with the error is return it to the original caller.

err_t func1(void)
{
}

err_t func2(void)
{
return func1();
}

In our project, almost the entire code base running on the uC is a library exposed via an IPC link. All errors are just propagated back up and eventually sent back across the link to the caller.
Directive 4.7 is about ensuring that the software does not neglect error conditions that may arise, but handles them as required. What is required is not specified by Directive 4.7, but rather should be specified as part of the software development process (see section 5.2 of the MISRA C 2012 Guidelines).

Static analysis tools may assist with the enforcement of Directive 4.7, by reporting situations such as error conditions that do not appear to be properly tested, or where data appears to be relied upon before checking for its validity.
However, it is ultimately down to manual review to assess whether potential errors are handled as intended.
It would be great if a newer version would address the issue of returning an error value.
If it's up to the development process to design, if returning a value is appropriate handling, the Directives wording "shall check for the indication of an error as soon as the function returns" is misleading. It appears as if returning an error value is not an option and some static checkers treat is as such.