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

Username
  

Password
  





  function
Posted by: mit_it - 06-01-2011, 06:40 AM - Forum: MISRA-C:2004 Exemplar Suite - Replies (1)

i am defining a fucntion and getting error just starting braces "Function declared at block scope"
'and Inserted ';' token in an attempt to continue parsing.

I have checked expalnation but didnt get proper resembles with my problem.

Print this item

  Rule 5-0-19: array of pointer, instead of, pointer to array
Posted by: fakoor - 14-12-2010, 05:35 AM - Forum: 6.5 Expressions (C++) - Replies (3)

Regarding these declarations:

Code:
int8_t * ptr6[ 10 ];
int8_t ** ptr7[ 10 ];

There are two type of explanations used:
  • pointer to array of some data type
  • array of pointer to some data type
I think the former style is more accurate, read more below:

In "Explanation of types" section, it is stated:
Quote:ptr6 is of type pointer to array of int8_t

Actually, it was expected to be stated this way:
ptr6 is of type array of pointer to int8_t

As a comparison, it is stated some lines later that:
Quote:ptr7 is of type array of pointer to pointer to int8_t

which is exactly accurate.

What is your idea?

Print this item

  Rule 5.2, at what scope is the rule broken?
Posted by: joa07 - 06-12-2010, 02:33 PM - Forum: 6.5 Identifiers - Replies (1)

Hello!

Rule 5.2 says that an identifier in a inner scope shall not hide an identifier in an outer scope.
I have two cases where I'm not sure what the rule says.

1. May a function use the name of an identifier that is local for this translation unit, but may be extern global for another translation unit? The first translation unit does not know this identifier at compile-time, so this error should only be detectable at link-time.

2. If the first question was a Yes, does this following code break this rule (it may brake some other Misra rules)?

Code:
int func1(void) {
    int var = 23;
    return var;
}

extern double var;    /* The name is reused here, global scope. Probably breaks rule 8.8 */

double func2(void) {
    return var;
}

Print this item

  Just to be clear on 0-1-8 ...
Posted by: gs - 19-11-2010, 06:56 PM - Forum: 6.0 Language independent issues (C++) - Replies (1)

The standard library implementation here has the body of one of the standard library functions defined as, literally, "{ }". The function does not do anything except go, "Yes, I have been called." Did MISRA intend to prohibit such a definition with respect to 0-1-8?

Print this item

  19.4 do while(0)
Posted by: Lundin - 17-11-2010, 11:06 AM - Forum: 6.19 Preprocessing Directives - Replies (4)

I would recommend the committee to rephrase rule 19.4 so that it does not allow do-while-zero inside function-like macros.

The do-while-zero mechanism has only two purposes:

Code:
/* "goto wrapper" */
do
{
  if(something)
  {
    break;
  }
  ...
} while(0);
The above code is a "hack" to stay compliant with rule 14.4 (goto shall not be used). But it surely leads to even less readable code than goto does.

Code:
/* "if-statement fiasco saver" */
#define FUNC(x) do
{
  do_this();
  do_that();
} while(0)  /* no semicolon here, as enforced by 19.4 */

if(something)
  FUNC(X); /* the macro allows the semicolon to be placed here */
else
The above is a "hack" that only applies to code non-compliant to rule 14.9 (if shall be followed by a compound statement). The sole purpose of do-while-zero is to save non-compliant code from the compiler errors it would otherwise receive! If the macro was written as two braces without the do while, there would be a compiler error because of the semicolon.

To sum this up: if code is to conform with (required) rules 14.4 and 14.9, then there is no reason for rule 19.4 to allow do-while-zero.

Print this item

  10.1: Can the underlying type of enum constants be unsigned?
Posted by: andersl - 09-11-2010, 11:57 AM - Forum: 6.10 Arithmetic Type Conversions - Replies (1)

After reading the MISRA-C:2004 guideline and earlier posts to this
forum, I have concluded the following about enum:s:

* An enum object is in standard C "int", and hence has the underlying
type "int".

* An enum constant has the underlying type corresponding to the
magnitude, as specified by the table in 6.10.4

However, this leaves one open question: What is the sign of an enum
constant?

The background is that in embedded devices, peripheral units are often
memory mapped and described using a struct, for example:

Code:
/* Typical peripheral usage */
enum my_enum
{
  FIELD1 = 0x01U,
  FIELD2 = 0x02U,
};
typedef unsigned short my_uint16_t;
struct my_struct
{
  my_uint16_t x;
} s;

void test1(void);
void test2(enum my_enum v);
void do_something(void);

void test1(void)
{
  s.x = (FIELD1 | FIELD2);
}
void test2(enum my_enum v)
{
  if (v == FIELD1)
  {
    do_something();
  }
}
/* End of example */
Back to the question: do enum constans get the same signedness as the
initializer expression. In other words, can enum constants be
unsigned?



Alternative 1: Always signed

If we assume that the underlying type is signed, then the assignment
in "test1" will break rule 10.1, as the expression to the right has
the underlying type "signed char".

If this is the case, enum can't be used to describe bits in bitmask in
a MISRA-C-compliant application. This is a big drawback and would make
MISRA-C much less useful in real-world applications, as it would force
peripheral units to be described using preprocessor macros.



Alternative 2: Get type from the initializer expression

On the other hand, if the enum constants inherit the underlying type
from the initializer expression, it could be something like "unsigned
char". In which case, any operation involving an enum object (int) and
enum constants (e.g. unsigned char) appears to break rule 10.1, as
there will be an implicit conversion from "unsigned char" to "signed
int". For example, see the comparison in "test2".

Also, if this enum constant inherit the signedness from initializer
expression, what happens when the expression is left out, should it
inherit the type from the previous enum constant?

Code:
enum my_other_enum
{
  AnUnsignedConstant = 0x10U,
  IsThisSignedOrUnsigned
}


To conclude, I would like to know if enum constants should inherit the
signedness from the initializer expressions and, if so, should the
tools issue a MISRA-C error for expressions involving enum objects and
enum constants?

By the way, I work for a company providing a MISRA-C checker. In order
to make the tools as good as possible, I would like to get a straight
answer to the questions I ask in relation to rule 10.1 -- whether or
not the example code breaks other MISRA-C rules is irrelevant.

Print this item

  Implicit type conversions in switch statements
Posted by: dcrocker - 02-11-2010, 05:48 PM - Forum: 6.15 Switch Statements - Replies (1)

I've a question concerning the following example:

Code:
int8 x;
...
switch(x)
{
    case 0:      /* valid */
    case 255:    /* valid? */
    case 1L:     /* invalid, implicit cast from long to int */
        ...
}

I would expect any good static checker to report that x can never equal 255 here. But is 'case 255:' actually a MISRA 2004 rule violation? The C standard says that the switch expression x gets promoted to 'int' in this case, so the type of the case label 255 does match the type of the promoted switch expression. I can't find any MISRA rule that says that we should consider the underlying type (instead of the promoted type) of the switch variable when deciding whether a case label is allowed or not. If "case 255:" was the only case label on some code, then rule 14.1 (no unreachable code) would apply; but in this example, there is no unreachable code.

Print this item

  Rule 12.6
Posted by: azukich - 27-10-2010, 03:55 PM - Forum: 6.12 Expressions - Replies (1)

Klocwork has been getting a number of complaints on our interpretation of rule 12.6. For example:

If(TRUE==TRUE) ...

So if TRUE is a Boolean. “==” is not of &&, ||, !. We report this as a violation, since the code should look like
If(TRUE) ...

Many people have debated this. Are we misunderstanding this?

Print this item

  12.4, reading volatile side effect
Posted by: jdp - 13-10-2010, 07:29 AM - Forum: 6.12 Expressions - Replies (6)

Hi,

It's the first Misra compliant project I'm involved in and I've some troubles to understand some rules. On in particular is rule 12.4. I've some expression like

Code:
if (xxx && REGISTER)
where REGISTER is a deference to a volatile pointer (represents the content of a microcontroller register) declared as following:

Code:
#define REGISTER            (*((uword volatile *) 0xEA2CU))

The right and of && doesn't comply to rule 12.4 because of the volatile access. I don't understand why reading a volatile content is not Misra compliant. The problem is that registers access are defined as volatile and I don't know how to overcome this to make my statement compliant.

Thanks for your help.

Print this item

  single super state
Posted by: ggentile - 05-10-2010, 09:07 PM - Forum: MISRA AC SLSF discussions - Replies (3)

Following MAAB 2.1 rule db_0137 a chart with single superstate is forbidden.
INstead MISRA SLSF rule #39 require 0 to N superstate.

We are close to the MISRA rule 39 in fovour of MAAB db_0137,

I'd like to have some comment on the decision (we agree to MISRA) not include db_0137.

Giacomo

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 379 online users.
» 0 Member(s) | 377 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: 35
Rule 0.1.2
Forum: 4.0 Language independent issues
Last Post: stephanmuench
21-11-2024, 01:12 PM
» Replies: 0
» Views: 44
A18-9-4
Forum: AUTOSAR C++:2014 rules
Last Post: cgpzs
23-10-2024, 12:04 PM
» Replies: 2
» Views: 393
A8-4-5: are partial moves...
Forum: AUTOSAR C++:2014 rules
Last Post: misra cpp
22-10-2024, 02:03 PM
» Replies: 1
» Views: 336
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,874
MISRA AC EC guidelines
Forum: MISRA AC SLSF discussions
Last Post: misra-ac
21-10-2024, 08:21 AM
» Replies: 4
» Views: 15,521
News on future releases
Forum: MISRA AC SLSF discussions
Last Post: misra-ac
21-10-2024, 08:05 AM
» Replies: 1
» Views: 5,706
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: 447