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

Username
  

Password
  





  Rule 4.1 Question
Posted by: fbdog - 01-05-2008, 02:49 PM - Forum: MISRA-C:2004 Exemplar Suite - Replies (1)

Hello,

I was just wondering if anybody has come across a possible discrepancy with the Exemplar Test suite 4.1. In the MISRA 2004 standard, Rule 4.1 states that "Only those escape sequences that are defined in the ISO C Standard shall be used". Section 5.2.2 of the ISO C standard lists valid escape sequences, but section 6.4.4.4 in the ISO C Standard also further defines escape clauses that are used.

The Rule 4.1 test case lists hexadecimal escape clauses as being non-compliant, but section 6.4.4.4 in the ISO C Standard indicates that hexadecimal clauses are valid.

I am just wondering if anybody has considered this is as a mistake in the test suite?

Thanks,
Jerry

Print this item

  Acceptable Escape Sequences?
Posted by: gs - 25-04-2008, 01:24 PM - Forum: 6.4 Character Sets - Replies (3)

Hi,
Rule 4.1 states

Quote:Only those escape sequences that are defined in the ISO C standard shall be used.
The explanatory text then refers the Reader to section 5.2.2 of the C99 Standard for a list of escape sequences. However, 6.4.4.4 also defines an escape-sequence syntax as
Code:
escape-sequence:
       simple-escape-sequence
       octal-escape-sequence
       hexadecimal-escape-sequence
       universal-character-name
and a hexadecimal-escape-sequence as
Code:
hexadecimal-escape-sequence:
       \x hexadecimal-digit
       hexadecimal-escape-sequence hexadecimal-digit

The use of '\x' i not mentioned in 5.2.2 as a valid escape-sequence. Are hexadecimal escape-sequences permitted under MISRA 2004 Rule 4.1?

Print this item

  Rule 19.4 -TC1 example incorrect?
Posted by: Graham Andrews - 17-04-2008, 04:19 PM - Forum: 6.19 Preprocessing Directives - Replies (1)

The rule states that C macros shall only expand to ...
This implies that the rule should only be invoked when the macro is expanded.
So for the not compliant example

Code:
#define CAT PI  /* non-parenthesised expression */
A checking tool should not attempt to check the violation until the macro is used.
In fact when CAT is being processed for expansion, it requires PI to be expanded. PI expands to 3.14159F, which is a constant, so its expansion is o.k. The expansion of CAT looks for other preprocessing tokens after PI has been substituted. There are no more tokens, so CAT expands to 3.14159F and is therefore not in violation of rule 19.4.
If the example had been written as
Code:
#define CAT PI + PI
Then the expansion of CAT would be to a non-parenthesised expression and rule 19.4 violated.

Print this item

  Rule 8.9 and macros
Posted by: william.forbes - 02-04-2008, 07:12 AM - Forum: 6.8 Declarations and Definitions - Replies (5)

I believe that a macro has no linkage and is not an object and therefore is not covered by rule 8.9 (or indeed rule 8.4)

My problem is that C allows for multiple definitions of the same macro provided that the definitions are identical:

#define BILL some text
.
.
.
#define BILL some text

As far as I can tell, the above is legal C code and appears to not violate any MISRA rule. This is obviously undesirable!

Is my understanding correct or is there a MISRA rule to forbid such code?

Thanks,
Bill Forbes.

Print this item

  MISRA-C: 1998 rule 107 rescinded
Posted by: richardb - 18-03-2008, 11:33 AM - Forum: MISRA-C:1998 to MISRA-C:2004 migration - Replies (1)

Can anyone tell me why the original MISRA-C rule 107 was rescinded in MISRA-C2? It related to not dereferencing the null pointer.
Thanks,
Richard.

Print this item

  Rule 3.6: Reserved words and standard library function names
Posted by: tria1312 - 12-03-2008, 11:39 AM - Forum: 6.3 Documentation - Replies (4)

Hi,

I'm using a tool from the USA called codechk.

When performing check on my code I get this message:

Code:
u16_t f29( void );
Quote:error: (REQUIRED) MISRA rule 116 ( 3.6 ) violated: Reserved words and standard library function names shall not be used { DECL }

But I dont see any reserved words or standard library function names. Can anyone help me out? Do you need some more code or infos?


Bjoern

Print this item

  Question regarding Integrity Analysis
Posted by: david ward - 04-03-2008, 12:42 PM - Forum: MISRA SA discussions - Replies (1)

The following question has been received by MISRA and is posted on behalf of the questioner:

Quote:Both the MISRA Integrity Report and the Safety Analysis Guidelines refer to the following probabilities:

Reasonably Possible
Unlikely
Remote
Very Remote
Extremely Improbable

However there is never an explicit definition of the probablities associated with these categories and the categories do not directly map onto the probabilities defined in Table A.2 of the integrity report. Are there explicit definitions for these categories or can I assume the following?

Probable = Reasonably Possible
Occasional = Unlikely
Remote = Remote
Improbable = Very Remote
Implausible = Extremely Improbable

Print this item

  Misra rule 42
Posted by: JeroenBoonen - 28-02-2008, 09:45 AM - Forum: General Questions - Replies (2)

Hi,

I have a question concerning rule 42, which states : \"comma operator shall not be used, except in the control expression of a for loop\".

Now what is \"the control expression\" in following instruction : for(i = 0; i < 10; i++) {...}

Is it \"i = 0\" or \"i < 10\" or \"i++\" ?

Currently we use a GreenHills compiler with build-in misra checking and they are saying it is \"i < 10\".
Searching on google:
IAR and ABRAXAS says it is \"i = 0\" and \"i++\"

Now hopefully you can give me the correct answer.

Thank you,

Jeroen

Print this item

  Rule 9.2 in TC1
Posted by: Lundin - 20-02-2008, 02:53 PM - Forum: 6.9 Initialisation - Replies (1)

I question the practical use of the text added to rule 9.2 in TC1. According to that rule, zero initialization of an array or struct can only occur at top level.

How do you write MISRA-C compatible code for this case:

Code:
typedef struct
{
  BOOL enabled;
  uint8_t buffer [5000];

} DataBuffer;


DataBuffer db = {TRUE};            /* not compliant, non-zero initialization */
DataBuffer db = {TRUE, {0} };      /* not compliant, zero initialization at sub level*/

DataBuffer db = {TRUE, /* what goes here? */ };

As the rule is now, the programmer who happens to have a data structure like the one above will have to type out 5000 zeroes in his source file to conform to MISRA-C.

I don't see why the second of those lines can't be allowed. The two non-compliant examples above are perfectly safe and will set the whole buffer to zero. ISO C is clear:

ISO 9899:1999, chapter 6.7.8 Initialization Wrote:21 If there are fewer initializers in a brace-enclosed list than there are elements or members of an aggregate, or
fewer characters in a string literal used to initialize an array of known size than there are elements in the array,
the remainder of the aggregate shall be initialized implicitly the same as objects that have static storage duration.
(I can only cite C99, not C90, though they are identical in this case)

The buffer is implicitly initialized as if it had static storage duration and is therefore set to zero.

The argument "the struct can be initialized to zero and the Boolean member can then be set to TRUE in runtime" is not valid, as the struct might be const.

Print this item

  Example for rule 11.1
Posted by: stefansta - 20-02-2008, 12:21 PM - Forum: MISRA-C:2004 Exemplar Suite - Replies (2)

Hello,
I have a question according to the example for the rule 11.1 (mc2_1101.c). My misra checker detects that the line \"pif32 int32p_fun = &get_int32\" violates rule 11.1, but I think this line is correct.
Am I right?

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 259 online users.
» 0 Member(s) | 257 Guest(s)
Bing, Google

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