Welcome to the MISRA discussion forum

The wording of 14.1 does not clarify the issue clear enough. I've discussed with several experienced persons and the common of these discussions is, that the questions only can be resolved, if someone ADDS personal interpretations. That cannot be the intension of a rule (text).

Firstly, \"defensive programming\" is not a misra rule. In my opinion this is a severe lack in/on the misra rule set. Although not explicitly defined its used in the rule text of 14.1 and its used in a confusing way: \"Code that can be reached but may never be executed is excluded from the rule (e.g. defensive programming)\".

In my tries to understand this, I refactored this sentence on following part (and nobody out of my discussions with Developers and QA Managers could give me an answer on that):

What is \"code, that can be reached but (may) never be executed\" ?

The provided example does not answer this question, because it shows code that \"exists but never will be reached\".

Maybe it helps to concretesize my intention when I re-word above sentence as follows: \"Is it possible, that code can be reached but not executed ?\"

Thanks in advance

Frank

Since, according to http://www.misra-c2.com/forum/viewtopic.php?t=264, the following code is not permitted:

Can you please supply an example of a violation of rule 19.9? This would help to understand what the rule is really trying to enforce.

In our code we want to use generic macros of kind

#define macro(a) int array[2] = {a, a};

unfortunately a do-while-zero loop does not helps, cause defined objects are only known within the loop.

So we would like to ask for a further exception of the described kind.

In the attachment you will find an example to demostrate the intention of such macros.
The program reads values of an Analog Digital Converter (via SPI) and writes modified values to a Pulswidth Generator (also via SPI).
All transfers are coded in an array (Transfer_List). The contents of the array depends on the hardware (baudrate, data-format) and the tranfer-typ (read, write
number of values). The C-file has no hardware dependant function. All hardware specific settings are encapsulated in the macro Create_Transfer_List.
Modifying the hardware only needs to modify the macro. Further I/Os can be implemented very easily.

We would appreciate your positve response.

Mit freundlichen Grüßen/Best regards,

Hans-Peter Lässle
Control Systems
ETC-D

Continental Teves AG & Co. oHG
Guerickestr. 7, D-60488 Frankfurt am Main
P.O. Box 900120, D-60441 Frankfurt am Main

Telefon/Phone: 0049 69 7603-5418
Telefax: 0049 69 7603-3990
E-Mail: [email protected]
http://www.contautomotive.com
_____________________________________________________

Continental Teves AG & Co. oHG, Guerickestr. 7, D-60488 Frankfurt am Main
Sitz der Gesellschaft/Registered Office: Frankfurt am Main, Registergericht/Registered Court: Amtsgericht Frankfurt am Main HR A 27047, USt.-ID-Nr./VAT-ID-No. DE 112160365
Gesellschafter/Shareholders: Continental Aktiengesellschaft (geschäftsführend/managing)
Vorsitzender des Aufsichtsrats/Chairman of the Supervisory Board: Dr. Hubertus von Grünberg
Vorstand/Executive Board: Manfred Wennemer (Vorsitzender/Chairman), Dr. Alan Hippe, Gerhard Lerch, Dr. Karl-Thomas Neumann, Dr. Hans-Joachim Nikolin, Heinz-Gerhard Wente, William L. Kozyra (stv./Deputy)
Sitz der Gesellschaft/Registered Office: Hannover, Registergericht/Registered Court: Amtsgericht Hannover HR B 3527
Continental Teves UK Ltd., Company Number 00700225, Ebbw Vale, Wales, Großbritannien/Great Britain
_____________________________________________________
Proprietary and confidential. Distribution only by express authority of Continental AG or its subsidiaries.

What is the preferred implementation of an infinite loop?

Why is it an example suite and not a test suite?

what can we use the example suite for?

This topic is for questions and discussions related to the Exemplar Suite. For questions or discussions relating to the Rules which arise from using the Exemplar Suite, please post these in the appropriate Rule topic.

MISRA is pleased to announce the availability of the following resources for MISRA C:

• Exemplar Suite
  
• Technical Clarification 1 for MISRA-C:2004.

This suite of files is intended to illustrate issues addressed by the MISRA C rules as expressed in:

1. MISRA-C:2004 Guidelines for the use of the C language in critical systems, ISBN 0 9524156 2 3 paperback and ISBN 0 9524156 4 X PDF.
   
2. MISRA-C:2004 Technical Corrigendum 1
   

Attached Files

  MISRA-C_exemplar_suite_2007_07_17.zip (Size: 126.71 KB / Downloads: 18)

Since the publication of MISRA C:2004, the MISRA C Working Group have developed the Exemplar Suite (see separate topic). During the development of the Exemplar Suite, and based on questions raised on this Forum, a number of issues have been identified. This document provides clarification on these issues. The clarifications described by this document are incorporated into the Exemplar Suite release 1.0 dated 17 July 2007.

This document is intended to be used in conjunction with a copy of MISRA C:2004.

Please note: copies of MISRA C:2004 purchased on or after 21 July 2008 are a revised edition that incorporates these changes in the text.

Attached Files

  MISRA_C2_TC1.pdf (Size: 475.48 KB / Downloads: 35)