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

Martin Sebor msebor at gmail.com
Wed Nov 28 19:10:52 GMT 2018


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.  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?  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.)

Martin

> In this respect, packed and non-packed
> structures are no different from one another: any packing/non-packing
> is just one of the way in which the compiler can define the behavior:
> 
>    6.7.2.1#14 Each non-bit-field member of a structure or union object
>               is aligned in an implementation-defined manner appropriate
>               to its type.
> 
> Here I am quoting C11 because I know that you care about that version
> of the language, whereas for MISRA C:2012 I would have to quote the
> equivalent sentences in C90 and C99.
> 
> In addition, to Directive 1.1, if the selection of a packed representation
> is done with special syntax (as opposed to be controlled from the command
> line), then advisory Rule 1.2 (Language extensions should not be used)
> might apply.
> Kind regards,
> 
>     Roberto
> 
> 
> On 11/28/18 4:33 PM, Robert Seacord wrote:
>> MISRA really requires strictly conforming programs?  I didn't think 
>> anyone tried to write strictly conforming programs because they are 
>> unreasonable.
>>
>> I've said this before, but I think confusing security and safety with 
>> portability.
>>
>> rCs
>>
>> On Wed, Nov 28, 2018 at 10:12 AM Clive Pygott <clivepygott at gmail.com 
>> <mailto:clivepygott at gmail.com>> wrote:
>>
>>     I'd agree that  __packed  is like a pragma, but pragmas are 
>> explicitly implementation defined. Whether you want to call that a 
>> language extension or not, it clearly takes you outside the domain of 
>> strictly compliant programs
>>
>>               Clive
>>
>>     On Wed, Nov 28, 2018 at 1:02 PM Wilson, Charles 
>> <Charles.Wilson at draeger.com <mailto:Charles.Wilson at draeger.com>> wrote:
>>
>>         I’m not sure I’d agree that this is an extension.____
>>
>>         __ __
>>
>>         I believe that it falls under the same category as pragmas, 
>> that is, guidance to the compiler.____
>>
>>         __ __
>>
>>         MSVC 
>> https://docs.microsoft.com/en-us/cpp/preprocessor/pack?view=vs-2017____
>>
>>         gcc 
>> https://gcc.gnu.org/onlinedocs/gcc-3.3/gcc/Variable-Attributes.html#Variable%20Attributes____ 
>>
>>
>>         keil 
>> http://www.keil.com/support/man/docs/armclang_ref/armclang_ref_chr1384946440202.htm____ 
>>
>>
>>         __ __
>>
>>         The clang sources provide an interesting view:____
>>
>>         
>> https://github.com/llvm-mirror/clang/blob/master/test/Sema/struct-packed-align.c____ 
>>
>>
>>         __ __
>>
>>         __packed is used in the keil ARM compiler____
>>
>>         
>> http://www.keil.com/support/man/docs/armcc/armcc_chr1359124968737.htm____
>>
>>         __ __
>>
>>         as well as the gcc ARM compiler____
>>
>>         
>> http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0491e/CJAFJHJD.html____ 
>>
>>
>>         __ __
>>
>>         An interesting side note is that all underscore prefixed 
>> things belong to the compiler.____
>>
>>         __ __
>>
>>         *From:* C-safe-secure-studygroup 
>> [mailto:c-safe-secure-studygroup-bounces at lists.trustable.io 
>> <mailto:c-safe-secure-studygroup-bounces at lists.trustable.io>] *On 
>> Behalf Of *Clive Pygott
>>         *Sent:* Wednesday, November 28, 2018 4:58 AM
>>         *To:* C Safety and Security Study Group Discussion 
>> <c-safe-secure-studygroup at lists.trustable.io 
>> <mailto:c-safe-secure-studygroup at lists.trustable.io>>
>>         *Subject:* Re: [C-safe-secure-studygroup] MISRA and packed 
>> structures____
>>
>>         __ __
>>
>>         Hi Robert____
>>
>>         __ __
>>
>>         What compiler are you using, as __packed isn't defined in 
>> either C11 or C17.    If its a compiler extension then you've already 
>> broken rule 1.2 "language extensions should not be used".  Its only 
>> advisory, so easy to deviate - but its a warning that you are now 
>> taking responsibility for the behaviour of the program.____
>>
>>         __ __
>>
>>         As far as memcpy is concerned, MISRA C:2012 has a number of 
>> examples that use memcpy, so its not totally banned. The examples all 
>> show array copying (where the implied pointer arithmetic is explicitly 
>> allowed), but my belief would be that copying a tMyStruct to another 
>> tMyStruct would be allowed using memcpy. What wouldn't be allowed 
>> would be copying to/from something of a different type, say an array 
>> of char.____
>>
>>         __ __
>>
>>              Clive____
>>
>>         __ __
>>
>>         __ __
>>
>>         __ __
>>
>>         __ __
>>
>>         On Tue, Nov 27, 2018 at 3:34 PM Robert Seacord 
>> <rcseacord at gmail.com <mailto:rcseacord at gmail.com>> wrote:____
>>
>>             Clive,____
>>
>>             __ __
>>
>>             In the following example:____
>>
>>             __ __
>>
>>             typedef __packed struct____
>>
>>             {____
>>
>>                            uint16 a;____
>>
>>                            uint8 b[ANNOYING_INCONVENIENT_LENGTH];____
>>
>>                            uint16 c;____
>>
>>             } tMyStruct;____
>>
>>             ____
>>
>>             tMyStruct buf;____
>>
>>             ____
>>
>>             Are you saying that 18.1 and 18.2 prohibit memcpy to &buf, 
>> ?____
>>
>>             __ __
>>
>>             Thanks,____
>>
>>             rCs____
>>
>>             __ __
>>
>>             On Tue, Nov 27, 2018 at 8:16 AM Clive Pygott 
>> <clivepygott at gmail.com <mailto:clivepygott at gmail.com>> wrote:____
>>
>>                 What do you mean by a packed structure?  The term 
>> doesn't appear in the C17 standard or MISRA C:2012____
>>
>>                 __ __
>>
>>                 If you mean using a structure with no or known padding 
>> as the target of a block move or I/O, then that has to be done by a 
>> deviation as it breaks the rules on pointer arithmetic (18.1/18.2) 
>> that only allow pointer arithmetic within an array____
>>
>>                 __ __
>>
>>                       Clive____
>>
>>                 __ __
>>
>>                 On Tue, Nov 27, 2018 at 12:05 PM Robert Seacord 
>> <rcseacord at gmail.com <mailto:rcseacord at gmail.com>> wrote:____
>>
>>                     Is there any MISRA rules which disallow the use of 
>> packed structures?____
>>
>>                     __ __
>>
>>                     rCs____
>>
>>                     _______________________________________________
>>                     C-safe-secure-studygroup mailing list
>>                     C-safe-secure-studygroup at lists.trustable.io 
>> <mailto:C-safe-secure-studygroup at lists.trustable.io>
>>                     
>> https://lists.trustable.io/cgi-bin/mailman/listinfo/c-safe-secure-studygroup____ 
>>
>>
>>                 _______________________________________________
>>                 C-safe-secure-studygroup mailing list
>>                 C-safe-secure-studygroup at lists.trustable.io 
>> <mailto:C-safe-secure-studygroup at lists.trustable.io>
>>                 
>> https://lists.trustable.io/cgi-bin/mailman/listinfo/c-safe-secure-studygroup____ 
>>
>>
>>             _______________________________________________
>>             C-safe-secure-studygroup mailing list
>>             C-safe-secure-studygroup at lists.trustable.io 
>> <mailto:C-safe-secure-studygroup at lists.trustable.io>
>>             
>> https://lists.trustable.io/cgi-bin/mailman/listinfo/c-safe-secure-studygroup____ 
>>
>>
>>         ---
>>         This communication contains confidential information. If you 
>> are not the intended recipient please return this email to the sender 
>> and delete it from your records.
>>
>>         Diese Nachricht enthaelt vertrauliche Informationen. Sollten 
>> Sie nicht der beabsichtigte Empfaenger dieser E-mail sein, senden Sie 
>> bitte diese an den Absender zurueck und loeschen Sie die E-mail aus 
>> Ihrem System.
>>         _______________________________________________
>>         C-safe-secure-studygroup mailing list
>>         C-safe-secure-studygroup at lists.trustable.io 
>> <mailto:C-safe-secure-studygroup at lists.trustable.io>
>>         
>> https://lists.trustable.io/cgi-bin/mailman/listinfo/c-safe-secure-studygroup 
>>
>>
>>     _______________________________________________
>>     C-safe-secure-studygroup mailing list
>>     C-safe-secure-studygroup at lists.trustable.io 
>> <mailto:C-safe-secure-studygroup at lists.trustable.io>
>>     
>> https://lists.trustable.io/cgi-bin/mailman/listinfo/c-safe-secure-studygroup 
>>
>>
>>
>> _______________________________________________
>> C-safe-secure-studygroup mailing list
>> C-safe-secure-studygroup at lists.trustable.io
>> https://lists.trustable.io/cgi-bin/mailman/listinfo/c-safe-secure-studygroup 
>>
>>
> 
> 
> 
> _______________________________________________
> C-safe-secure-studygroup mailing list
> C-safe-secure-studygroup at lists.trustable.io
> https://lists.trustable.io/cgi-bin/mailman/listinfo/c-safe-secure-studygroup
> 




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