MISRA Discussion Forums
Portal

Welcome, Guest
You have to register before you can post on our site.

Username
  

Password
  

  Rule 19.4, does order of #definition matter?
Posted by: gs - 11-11-2005, 07:23 PM - Forum: 6.19 Preprocessing Directives - Replies (1)

The MISRA II documentation states the following is compliant with the requirements of rule 19.4:

#define A 8
#define B A

However, it does not specifiy whether the following is also compliant:

#define B A
#define A 8

In the latter case, B does ultimately expand to 8, a constant, adhering to rule 19.4. However, at the time of #definition, B does not expand to a constant, braced initializer, parenthesized expression, type qualifier, storage class specifier or do-while-zero construct. Only after processing the #definition for A, is compliance certain (future re-#definition notwithstanding). My question: at what code processing point, does MISRA II, Rul 19.4, require the macro to evaluate to the prescribed formats? At the end of all preprocessing? At #definition time? Sometime else?

Print this item

  Arithmetic on Pointers are MISRA compliant ?
Posted by: lv - 31-10-2005, 04:35 PM - Forum: 6.17 Pointers and Arrays - Replies (1)

The rules 17.1 to 17.3 give some possibilities to manipulate pointers (arithmetic, substraction, comparison) whereas the rule 17.4 doesn't authorize pointer manipulation in any way other than array indexing.

Should it be possible to explain me where I make a mistake in my understanding?

In particular, I would like to know if the following code is MISRA 2004 compliant concerning pointer manipulation:

Code:
    unsigned int tab[10];
    void test(void)
    {
        unsigned int *ptr;

        ptr = &tab[2];
        *ptr = 33;
        ptr++;                         /*  MISRA Compliant ? */
        *ptr = 11;
    }

I thank you in advance.

Best regards.

Print this item

  Rule 10.5 (required) and use of <<=
Posted by: Achim Olaf Zacher - 19-09-2005, 02:47 PM - Forum: 6.10 Arithmetic Type Conversions - Replies (1)

Rule 10.5: result of ~ and

Print this item

  Rationale for no goto, continue but allow break
Posted by: niall - 14-09-2005, 02:55 PM - Forum: 6.14 Control Flow - Replies (3)

I know this should have been brought up before, but in reviewing MISRA-2 this passed me by.
Being pedantic, why has the rule on break (14.6) been relaxed and not 14.5 (or 14.4)?
A break in a loop is just a goto!
I have no problem with it, it just smacks of inconsistency.

Print this item

  Examples
Posted by: MISRA Reply - 09-09-2005, 02:21 PM - Forum: 6.19 Preprocessing Directives - No Replies

Code:
#define M1 ;

This macro breaks rule 19.4. Macro expanding to Null statement is not allowed/

Code:
#define M2
#define M3 /* comment */

This macro expands to no body, and is therefore not prohibited by 19.4.

A comment in a macro definition is removed by the pre-processor. Rule 14.3 applied before
Pre-processing. Treatment of M2 and M3 is identical.

Code:
M1

Since definition of M1 macro was invalid, its use is already a violation.

Code:
M2;
M3;

After pre-processing, these are both Null statements. Before pre-processing, there are characters before the Null statement. This is not allowed by 14.3.

Print this item

  What is the essential requirement of Rule 13.3 ?
Posted by: Gavin McCall - 09-09-2005, 01:39 PM - Forum: 6.13 Control Statement Expressions - No Replies

Question: What is the essential requirement of Rule 13.3 ?

Rule 13.3 only prohibits the use of == and !=.

Does this mean that it is legitimate to use the >= and 10.0f ) /* compliant */
…
if ( speed = (10.0f – tolerance)) && ( speed

Print this item

  What is the character set referred to in Rule 3.2?
Posted by: Gavin McCall - 09-09-2005, 01:37 PM - Forum: 6.3 Documentation - Replies (1)

Question: What is the character set referred to in Rule 3.2?

Answer: MISRA C Steering Team

There are two character sets.
The source code is written in one character set.
The program can execute with input/output in a second character set.
These may or may not be the same.
Both the basic source character set and the basic execution character sets shall be documented.
This rule allows free choice of character sets for coding and execution. This use shall be documented.

Print this item

  Is Rule 20.1 applicable to \"defined\"?
Posted by: Gavin McCall - 09-09-2005, 01:30 PM - Forum: 6.20 Standard Libraries - No Replies

Question: Is Rule 20.1 applicable to \"defined\"?

(a) We presume that \"#define defined (10)\" will be in violation of Rule 20.1.

(b) If our presumption is correct, then which of \"reserved identifier\", \" macro\" or \"function\" will \"defined\" be?
We could not find the answer in ISO/IEC 9899:1990. Is it described somewhere in COR1, COR2 or AMD1?

Answer: MISRA C Steering Team 7/9/2005

(a) YES - defined is included in the text under the rule.

(b) defined is listed under 6.8.8 Predefined Macro Names.
It is also listed in Appendix G: Undefined Behaviour 54.

Print this item

  What about keywords?
Posted by: Gavin McCall - 09-09-2005, 01:04 PM - Forum: 6.20 Standard Libraries - No Replies

Question:

Is it correct to think that a keyword is out of the scope of Rule 20.1?

For example, \"#define int (10)\" violates Rule 19.4, doesn't it?

Answer: MISRA C Steering Team 7/9/2005

Keywords (as defined in 6.1.1) shall be considered to be in the scope of 20.1.
This is detailed in the supporting text and will be clarified in the Technical Corrigendum.

#define int (10)

This is not a violation of 19.4.

19.4 is concerned with the replacement text of a macro, and not its name.

Print this item

  Clarification of 20.1 - Intrepretation of \"not to be d
Posted by: Gavin McCall - 09-09-2005, 01:00 PM - Forum: 6.20 Standard Libraries - No Replies

Question 2: Interpretation of \"not be defined, redefined\"

a) Does it mean that \"#define\" is not allowed?

b) Is it not allowed to define as an object or a function, either?

Answer: MISRA C Steering Team clarification 7/9/2005

(a) YES - To define an object or a function with the name of a reserved identifier is prohibited under rule 20.2.

(b) YES - To #define macros with the name of a reserved identifier is prohibited.

Print this item

Search Forums

(Advanced Search)

Forum Statistics
» Members: 6,171
» Latest member: stephanmuench
» Forum threads: 998
» Forum posts: 2,752

Full Statistics

Online Users
There are currently 666 online users.
» 0 Member(s) | 664 Guest(s)
Bing, Google

Latest Threads
Rule 6.2.1: non-inline co...
Forum: 4.6 Basic concepts
Last Post: cgpzs
Yesterday, 10:11 AM
» Replies: 0
» Views: 21
Rule 0.1.2
Forum: 4.0 Language independent issues
Last Post: stephanmuench
21-11-2024, 01:12 PM
» Replies: 0
» Views: 31
A18-9-4
Forum: AUTOSAR C++:2014 rules
Last Post: cgpzs
23-10-2024, 12:04 PM
» Replies: 2
» Views: 355
A8-4-5: are partial moves...
Forum: AUTOSAR C++:2014 rules
Last Post: misra cpp
22-10-2024, 02:03 PM
» Replies: 1
» Views: 317
model information blocks ...
Forum: MISRA AC SLSF discussions
Last Post: misra-ac
22-10-2024, 01:27 PM
» Replies: 1
» Views: 4,437
MISRA AL SLSF - Rule 043I
Forum: MISRA AC SLSF discussions
Last Post: misra-ac
22-10-2024, 01:11 PM
» Replies: 1
» Views: 8,854
MISRA AC EC guidelines
Forum: MISRA AC SLSF discussions
Last Post: misra-ac
21-10-2024, 08:21 AM
» Replies: 4
» Views: 15,484
News on future releases
Forum: MISRA AC SLSF discussions
Last Post: misra-ac
21-10-2024, 08:05 AM
» Replies: 1
» Views: 5,682
Signal naming convention ...
Forum: MISRA AC SLSF discussions
Last Post: misra-ac
21-10-2024, 07:57 AM
» Replies: 1
» Views: 7,237
Rule 7.0.2: operator cons...
Forum: 4.7 Standard conversions
Last Post: karos
14-10-2024, 08:52 PM
» Replies: 2
» Views: 424