Welcome to the MISRA discussion forum

... between a pointer to object type and a different pointer to object type (advisory).

Additional comment: \" Conversions of this type may be invalid if the new pointer type requires a stricter alignment.\"

---

I think there can be further risks. I suppose - e.g. - casting a signed pointer onto an unsigned pointer (of the same bitwidth and alignment) itself is not risky. Dangerous can be to WORK with the casted pointer regarding its content, it is pointing onto. In this case the cast itself would not be dangerous, but the possibilities afterwards are.

example:

unsigned int foo (signed int* ps)
{
unsigned int* pu;

pu = (unsigned int*) ps; // assumed to be no problem itself
*pu = ... ; // assumed to be no problem itself
// but can be a problem later, when the content of the incoming pointer is used afterwards
}

Can anybody confirm ? I think it can be of interest to know the problems in more precision. Does anybody know other implications (not applying such casts) ?

Regards,
Frank

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)