[C-safe-secure-studygroup] MISRA and packed structures

Martin Sebor msebor at gmail.com
Wed Nov 28 22:23:42 GMT 2018


On 11/28/18 1:06 PM, Roberto Bagnara wrote:
> On 11/28/18 8:10 PM, Martin Sebor wrote:
>> On 11/28/18 9:03 AM, Roberto Bagnara wrote:
>>>
>>> I am caught by the doubt my message was not received.
>>> I wrote:
>>>
>>> As everything concerning the memory representation of structures
>>> is implementation-defined, Directive 1.1 (Any implementation-defined
>>> behaviour on which the output of the program depends shall be documented
>>> and understood) applies.
>>
>> I would be more than surprised if any real software conformed to
>> this requirement in a meaningful way.
> 
> Hi Martin.
> 
> I guess you mean "real software *project*", because this directive
> involves both the code and the process (in that it required to document
> and understand things).
> 
>> Take, for instance, 5.2.4.1
>> Translation limits.  How many projects have you seen that count
>> the number of blocks, parentheses, or identifiers in their code
>> to make sure they either don't exceed those limits or document
>> their requirements beyond what the standard guarantees?
> 
> All projects that claim MISRA C compliance have to comply to Directive
> 1.1 or formally deviate it.  Any good MISRA C tool will do the
> counting and report when limits are exceeded; any such tool will also
> allow users to specify the limits that are guaranteed by the compiler.

No, that's not permitted by the wording of the directive:

   Dir 1.1  Any implementation-defined behaviour on which the output
   of the program depends shall be documented and understood

Even if a compiler has no limits on the number of blocks, parens,
or identifiers in a translation unit, as stated, the directive
still requires the project to document each time they exceed
the limit.

Configuring the analysis tool to only diagnose exceeding the more
permissive limits of the compiler rather than the minima outlined
in the C standard would defeat its purpose -- the tool would no
longer detect relying on implementation-defined behavior but rather
on undefined behavior.

> So with a good tool there is no manual counting work to be done.

Documenting it is still required, and an entirely pointless
exercise.

> 
>> How many developers have you ever come across that understand what
>> it means to exceed these limits, or even that some of those limits
>> exist?  (Heck, even some members of WG14 don't fully appreciate what
>> it means.)
> 
> Developers who are meant to develop reliable code in C must be trained
> to understand these things (e.g., undefined behavior), for otherwise
> they cannot do the job properly.  Lack of understanding can be slightly
> mitigated by the use of tools that enforce sane coding rules preventing
> the bad things from happening, but we all know that, without training,
> this won't work (developers who do not understand will do bad things
> to the code in order to silence the tool).
> 
> My understanding is that what you wrote is equivalent to: "Many developers
> out there do not understand C well enough and do not use tools that
> warn them when they do dangerous things."  To which I would answer:
> "Code that is written by such developers in that way will most likely
> be neither safe nor secure."

Yet that's the vast majority of developers and code out there.
Thinking otherwise would be detached from the real state of
the software industry.  Expecting directives like "Thou shall
understand what you're doing" to change that would be naive to
put it mildly.  Static analysis tools that report things like
exceeding the limits in 5.2.4.1 or processes that force engineers
to document when they are exceeded irrespective of support for
doing so in the compiler they are using are worse than useless:
they take engineers' focus away from real problems and waste
their time and effort on dealing with bureaucratic requirements
that have nothing to do with safety or security.

Martin



More information about the C-safe-secure-studygroup mailing list