Welcome to the MISRA discussion forum

I've updated the phpbb code today to fix some security concerns.

If you spot something not working, please let me know.

--------------
IT Manager

In the beginning \"C\" was considered unsuitable for safety critical and safety related systems, however, it was so used ...

In 1998, as a response to this situation, MISRA produced MISRA C, a set of guidelines to aid the development of safety related systems in \"C\" in the automotive world. Since then, MISRA C has been adopted by the wider embedded systems community and has become the dominant, international coding guidelines for the use of \"C\" in critical systems. The MISRA C guidelines are widely accepted as fulfilling the requirements for a language subset as required by both the 1994 MISRA \"Development guidelines for vehicle based software\" and IEC 61508.

Things move on, and now C++ is in the position once held by \"C\"; many people believe that it should not be used for critical systems, but its use within the field is growing and that growth is without a common set of guidelines.

MISRA has recently started work on the production of a set of guidelines for the use of C++ in critical systems, the output of which will be a set of guidelines similar to those that were produced for \"C\".

The work, like other MISRA work, will be done on a voluntary basis. As such, MISRA is currently looking for 3 to 5 additional people to participate in the development of MISRA C++. We are looking for dedicated people who can contribute to a two day, focused working meeting once a month and who are also willing to put in effort \"off-line\".

If you are interested in taking part, please send your details to the chairman of the working group, Chris Tapp (chairman (at) misra-cpp.org). A brief note on your background would be appreciated, especially as we expect to receive too many volunteers and will have to make some tough choices!

It has been reported that the mail digest system has not been working for some time. My apologies to all who have been affected by this outage.

When we moved the MISRA-C2 website to a new server, the batch job to mail out the digest each hour was omitted. It has now been reinstated, and appears to be mailing out digests OK.

You can subscribe/unsubscribe to digests of the forum using the link at the top of the page. Set the options to receive the digests of what you want, when you want it and click on the \"update\" button. It should then mail out as you request. Note that the hour is GMT, so you'll need to take that into account when electing the time to receive the digests.

Thanks

In order to make this bulletin board more user-friendly and accessible, it is no longer necessary to log in to view posts. It is still necessary to be a registered user and to log in to make posts.

If you have any comments or concerns please contact the forum admin.

Whenever you change the definition of an array, the corresponding declaration for external linkage may need to be adapted (different size of array). This is error-prone since the declaration usually is included in a file different from the file with the definition. As a consequence, the code becomes inconsistent and more difficult to understand.
Moreover, the size information in the declaration with external linkage is redundant. Compilers usually ignore it.
So what are the benefits of having rule 8.12 classified as a \"required\" rule?

Hello All.

I am running the comercial RTOS Salvo through the MISRA checker as implemented in IAR's EWARM v4.20A tool suite.

I have a struct called ecb which in turn contains a field called tcbP. ecbP is a pointer to the struct ecb. OSeligQP is a pointer to a struct tcb.

The IAR MISRA checker complains about a call to a function

I belong to the Formal Verification group of Bhabha Atomic Research Centre. I wish to promote the use of MISRA C guidelines in my company. A list of companies in various sectors such as aerospace and military, that have accepted MISRA C standards, will help me a lot. May I ask the members of this group to help me.

Babita.

Hi there,

is there any Code Formatter / Beautifyer that reformats C code according to the MISRA rules, e.g. MISRA2 Rule 14.9 or Rule 14.8 or MISRA1 Rule59 ?

I know of artistic style (on sf) but unfortunately it has not the rule

kind regards,
Bernhard.

10.1a prohibits implicit conversions of an integer expression if it is not to a type wider than the underlying type (and of the same signedness). Suppose ints are the same size as shorts on my system, can I implicitly convert an short to an int? Technically, the ints are not wider than shorts, but nominally, they are. Any thoughts?

Our product makes use of a \"service-based\" architecture - and, while it is \"good code\" that runs on 16, 32, and 64 bit environments, it wasn't initially written with MISRA compliance in mind, although we're \"pretty close\". The tricky one is Rule 104...

Anyway, since networking, IPC, and other typical PC-and-up options for doing services aren't often available in constrained embedded environments, we've chosen function pointers and a \"registration\" methodology as our approach. We're an ISV that works with customers who typically write services themselves or use one of several service implementations that we provide. Services are things like file-system API interfaces, flash I/O interfaces, memory management, etc.

So, I have a question about Rule 104: it would seem that Rule 104 disallows this sort of approach, if I read it right: services are ultimately dynamically-created structures that contain arrays of function pointers that execute the different operations of the service.

The only \"get out of jail free\" card that I can see is that these pointers are set only once at registration time and not changed while the instance of the service exists. But the function pointers are initialized at runtime, so it would seem that we're still in violation of Rule 104.

Is \"initialized at runtime\" versus \"initialized at compile-time\" the test for Rule 104 compliance? Or is it \"a function pointer that is changed\", versus one that is initialized once, whether at compile or runtime, and not changed afterward?