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.
My questions:
1. Is my implementation of F1 above correct?
2. What should a compliant static analysis tool report, when F1 does not throw?
3. Shall a compliant AUTOSAR C++ checker tool here report a violation (error/warning/...) or is this kind of a hint or note?
4. What shall be reported for the operator()() of a lambda that does not throw and does not explicitly add noexcept (example: auto l = [font=Consolas, "Liberation Mono", Courier, monospace, Consolas, "Courier New", monospace][]() { return42; }[/font])?
5. (Bonus question) will a similar check be added to the next version of MISRA C++?
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?
Quote:Data members or base classes initialization in move constructor needs to be done with move semantics.
Does this mean that in order to comply with the rule, all data members in a move constructor must be initialized with move semantics, and thus no data members may be default constructed in a move constructor?
The text of the rule does not go that far, it merely prevents the use of copy semantics in move constructors.
Hello, in a company where I work, we have a license for MISRA C:2012 guidelines document allowing 100 people to see its content. We would like to avoid having a local copy of this PDF document for each reader. So, now we are sharing the document on sharepoint, where the access is controlled and there is a setting that does not allow downloading the PDF, only to open it in a web browser. This would be fine, however, we are also working on new company coding guidelines and it would be very good if we could create links to specific pages of MISRA C guidelines PDF. Normally, it is possible to add for example "#page=3" at the end of an URL address for the PDF document and it will open it in 3rd page. However, with the document in sharepoint, restricted only for specific users and with disabled download, it is not possible to reference the specific page using this method. For some reason it seems to work only with unrestricted documents.
So, do you have some other recommended ways of storing the MISRA documentation that allow showing only the content in web browser, without downloading and where only selected people can access it, while also being able to create links to specific pages?
we stumbled upon a few situations in which rule A5-16-1 is not particularly clear.
(1) The example contradicts the rule text as the usage of ?: as sub-expression in assignments (which is an expression again) is named compliant. This was already mentioned in https://forum.misra.org.uk/thread-1612.html .
(2) Code like "A a = 1 ? x : y;" where A is a class and x and y are objects of A. Assuming assignments are okay for this rule, the ?: is not the operand of the assignment but of an implicit call to the copy constructor of A. Should such implicit calls be ignored (aka treated as transparent) or is the rule okay with usage of ?: as function call argument in general?
It would be great if the exceptions for this rule could be clarified. Thanks a lot!
We report a 14-7-1 defect, as non-specialized SomeClass is never instantiated.
They're complaining it's a false positive. Could we get a ruling? Arguably the explicit specialization and the non-specialization are different classes, and to be compliant both should be instantiated. On the other hand, this might be a reasonable thing to do if e.g. the goal is to prevent the code from working with <false> (note: I'm only guessing at the goal. The example from the customer doesn't go much further than this)
Do you have any guidance?
could anyone help explain the following sentence in the Rationale part of Rule 8.7
Quote:Restricting the visibility of an object by giving it internal linkage or no linkage reduces the chance that
it might be accessed inadvertently.
as specified by the C standard:
Quote:If the declaration of an identifier for a function has no storage-class specifier, its linkage
is determined exactly as if it were declared with the storage-class specifier extern. If
the declaration of an identifier for an object has file scope and no storage-class specifier,
its linkage is external.
if an object is declared with no linkage, the default linkage is external linkage, so why giving no linkage to an object could restrict the visibility and reduces the chance that it might be accessed inadvertently?
Quote:Note also that all the elements of arrays or structures can be initialised (to zero orNULL) by giving an explicit initialiser for the first element only. If this method of initialisation is chosen then the first element should be initialised to zero (orNULL), and nested braces need not be used.
Is the zero initialization of foobars compliant with Rule 9.2?
Lint is complaining about this kind of initialization, but I'm not sure if it is right or not
Warning: LINT [W940] omitted braces within an initializer [MISRA 2004 Rule 9.2]
The rule mentions that the first element should be initialized to zero. The first element, which can be listed in the initialization list, would be the member foo of the first struct of the first array element. Setting this to 0 would, in my understanding, comply with rule 9.2. As in the last sentence "... nested braces need not be used" is mentioned, no further braces around the 0 are required.
We are pleased to announce the publication of MISRA C:2012 Technical Corrigendum 2 (MISRA C:2012 TC2). This document provides additional clarification on MISRA C:2012 and should be read in conjunction with either
MISRA C:2012 (Third Edition, First Revision) Guidelines for the use of the C language in critical systems, as revised by
MISRA C:2012 Amendment 2, Updates for ISO/IEC 9899:2011 Core functionality
or
MISRA C:2012 (Third Edition) Guidelines for the use of the C language in critical systems, as
revised by:
MISRA C:2012 Amendment 1, Additional security guidelines for MISRA C:2012
MISRA C:2012 Amendment 2, Updates for ISO/IEC 9899:2011 Core functionality
