Welcome to the MISRA discussion forum

The 'A7-1-1' uses the term: 'immutable data declaration'. This is not defined in the C ++ standard, so it is unclear if this rule applies to function parameters.

Quote:A5-2-6 (Required) : The operands of a logical && or \\ shall be parenthesized if the operands contain binary operators.

Could someone please explain why the "if (u && (boolean1 <= boolean2));" in Rule A5-0-2 is non-compliant.

Could someone please explain why the "if ( u8 && (bool_1 <= bool_2 ) )" in Rule 5-0-13 is non-compliant.

The Rule 11.3 (category Required) disallows the conversion between two pointers to different object types, indicating in the first paragraph the possible problems due to different alignment, and in the second paragraph that even if same alignment it is undefined behavior anyway (citing C99 section 6.5p7), except if conversion to pointer to a char type.

Even if the rule is technically correct, in my opinion readers will normally focus on the first paragraph, just analysing the alignment restrictions (and endianness) of the specific platform for justifying specific deviations (like using type punning through pointer conversion for needed format conversions). For example, justifying the conversion of a uint32_t into an array of two uint16_t, or a 32-bit float into a uint32_t. However, the part about undefined behavior is probably not highlighted enough, specially now that current compilers will take advantage of this undefined behavior to generate broken code due to the type aliasing analysis (reordering assignments or even removing code as the compiler is not required to consider the dependencies between those objects due to the undefined behavior, unless aliasing through a char pointer type or due to a few other exceptions).

I think it would be much more useful for the reader to mention the "strict aliasing rule" (as this is the term normally used to warn about these problems in technical forums) and the possibility to get "miscompiled" code at high optimization levels. Also, I think it would be very appreciated to give some guidance of possible standard-compliant solutions like using memcpy instead (moreover as the compiler will probably remove the call overhead if optimizations enabled), copying into an union (which may also be optimized by the compiler, not really generating any data copy) if the compiler is compliant with C99 T3, or even disabling the strict aliasing when compiling (like using -fno-strict-aliasing in GCC), in addition to the already mentioned access through a pointer to a char type.  Even if it cannot be ensured the universal adequacy of these solutions, the readers will be warned about sophisticated compilers and the strict aliasing rule, and will be aware about possible solutions available to be considered in their specific platform. Thank you very much.

Best regards,
Santiago

Regarding usage of bitfields and enum, it is mention thta in certain cases it can be acceptable.

Rule 9-5-1 :  Could you please explain what it means by "all relevant implementation-defined behavious is documented"
Rule 9-6-1 :   Could you please see if the following code example would be compliant.


For exemple would the following code be acceptable with a deviation justification:

   typedef unsigned int  ubitfield_t;

    union EventSource
      {
        EventSource() { Reset(); }
        void    Reset() { all[0] = 0; }

        uint32_t all[1];
        struct EventSourceBits
        {
            ubitfield_t unused                            : 28;

            ubitfield_t unknownId            : 1;
            ubitfield_t InvalidHeader         : 1;
            ubitfield_t wrongCRC              : 1;
            ubitfield_t incompatible          : 1;

        } bits;
      };



Regards,
Charles

In the interest of promoting best practices in developing safety- and security-related electronic systems and other software-intensive applications it would arguably be important to make coding guidelines, such as the coming version of MISRA C++ guidelines, highly available for anyone to use.

The open source community has been reluctant to try to implement support for checking compliance with previous MISRA C++ Guidelines in static analysis tools because they are not openly published. I'm proposing that it would be of great value to the automotive industry as a whole if MISRA C++ Guidelines were published under a copyright license which explicitly allows free use of the guidelines e.g. for use as a specification for implementing support for the Guidelines in opens source static analysis tools.

Is there anything currently preventing MISRA from taking such an approach to publishing of guidelines?

Hi,

I sent you a question before for TC3 issue - indeed I noticed that the C standard has  TC3 where there are some added things, this is resolved now, but I have one more issue I didn't find an fix for:

Mainly, in the appendix H.2. Critical Unspecified behavior, there seems to be a mistake in rules mentioned for the unspecified behaviors.
Mainly for C99, unspecified behaviors with ID 41 and 42, have Rule 21.9 - but they obviously refer to dynamic allocation, which should be Rule 22.1.

Further more, IDs 43 and 44, which should refer to quick sort and binary search, have Rule 21.10 (for time and date functions) but it should be Rule 21.9.

Finally, IDs 45 and 56, which should be covered by rule 21.10 (no time and date), do not have any reference to rules which avoids the unspecified behavior.

Please see attachment image for more details.

Attached Files

Thumbnail(s)
   

Hi experts,

A15-4-4 

Quote:Rule A15-4-4 (required, implementation, automated)

A declaration of non-throwing function shall contain noexcept specification.

What is the meaning of different naming conventions with rules?
For example, “Rule 2.1: A project shall not contains unreachable code” versus “Rule 5-0-7: There shall be no explicit floating-integral conversions of a cvalue expression”.
It seems some companies that use MISRA support only the decimal point rules, while others support the dashed rules.
What is the difference, and/or why is there a split?