Welcome to the MISRA discussion forum

This new forum has been set up for asking questions about and discussing MISRA's \"Guidelines for the application of MISRA-C:2004 in the context of automatic code generation\" (otherwise known as MISRA AC AGC).

The Working Group responsible for the MISRA AC AGC document will consider questions posted here and if appropriate give an official response (which will be posted by the \"MISRA Reply\" user). Any other comments and responses from any posters shall not be considered an official MISRA position.

We expect to respond to questions on an approximately monthly basis so if you don't hear from us, please be patient.

Steve Montgomery
MISRA Autocode Guidelines Project Leader

This new forum has been set up for asking questions about and discussing MISRA's \"Modelling style guidelines for the application of TargetLink in the context of automatic code generation\" (otherwise known as MISRA AC TL).

The Working Group responsible for the MISRA AC TL document will consider questions posted here and if appropriate give an official response (which will be posted by the \"MISRA Reply\" user). Any other comments and responses from any posters shall not be considered an official MISRA position.

We expect to respond to questions on an approximately monthly basis so if you don't hear from us, please be patient.

Steve Montgomery
MISRA Autocode Guidelines Project Leader

This is the example spreadsheet that corresponds to the MISRA SRfP example in Figure 9 of the document.

Attached Files

  MISRA_SRfP_example.xls (Size: 16 KB / Downloads: 19)

This example has been relocated to the \"Resources\" section. This section is visible to registered users after login.

This area of the Forum provides downloadable resources associated with MISRA Publications.

Please note that by downloading a resource you accept the license conditions associated with it.

Further details are given with each file.

This new forum has been set up for asking questions about and discussing MISRA's \"Guidelines for safety analysis of vehicle based programmable systems\" (otherwise known as MISRA SA and MISRA Safety Analysis).

The Working Group responsible for the MISRA SA document will consider questions posted here and if appropriate give an official response (which will be posted by the \"MISRA Reply\" user). Any other comments and responses from any posters shall not be considered an official MISRA position.

We expect to respond to questions on an approximately monthly basis so if you don't hear from us, please bear with us as we have day jobs to do too!

It is clear that implementing the MISRA code guidelines costs a lot in training, and that it bloats source code to some extent. Do the guidelines provide more benefit than their cost? I am somewhat sceptical about these benefits.

The MISRA guidelines have been in use for around a decade. There will thus surely have been some studies undertaken that demonstrate that the MISRA guidelines work, for some value of \"work\". Or, more accurately put, that determine in which circumstances they are useful and in which they are not.

I am disappointed not to be able to find any references to these studies on the MISRA web site. I wasn't able to find any with an internet search (though my googling skills are not that good).

Would somebody please point out these studies to me?

Thanks in advance!

--
Alan Mackenzie (Nuremberg, Germany).

Hi folks,

I had read in an article by Mr. Chris Hills http://(http://www.phaedsys.org/papersese0604.html)a few days back mentioning that the exemplar suite for the MISRA-C:2004 would be uploaded in a few days.
When can I expect the exemplar suite for MISRA-C:2004 to be uploaded? If its already uploaded, could I know the url to download it from.

Regards,
Rahul Mishra

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