Welcome to the MISRA discussion forum

Question:

Question 1: Interpretation of \"Reserved identifiers, macros and functions in the standard library\"

Does this phrase mean
a) \"Reserved identifiers
AND
macros in the standard library
AND
functions in the standard library\"
or
b) \"Reserved identifiers in the standard library
AND
macros in the standard library
AND
functions in the standard library\" ?

It seems that in case of a) above, \"#define __ABC (10)\" violates Rule 20.1 whereas it does not in case of b), because \"__ABC\", which is a reserved identifier, is not in the standard library. Moreover, it is not guaranteed that all of \"__LINE__, __FILE__, __DATE__, __TIME__, __STDC__ \"
are in the standard library. If not in the standard library, it is presumed that they can be \"defined, redefined or undefined\". Which interpretation should we take, a) or b) ?

MISRA C Steering Team Answer (7/9/2005)
Option A.
Reserved identifiers are defined by ISO/IEC 9899:1990 sections 7.1.3 Reserved Identifiers, 7.13 Future library directions and 6.8.8 Predefined Macro Names.
Macros in the standard library are examples of reserved identifiers.
Functions in the standard library are examples of reserved identifiers.

Any identifier in the standard library is an example of reserved identifiers.

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?