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

Username
  

Password
  





  Rule 20.9
Posted by: Nuria - 21-02-2006, 10:56 AM - Forum: 6.20 Standard Libraries - Replies (1)

Rule 20.9 says that the input/output library shall not be used in production code.

We can not use the function open because is not ANSI C. Which would be the alternative to open a file instead of fopen?

Thanks.

Print this item

  Rule 2.1
Posted by: nikunj - 16-02-2006, 07:22 AM - Forum: 6.2 Language Extensions - Replies (4)

What are the possible scenarios in which Rule 2.1 will be violated?

Rule allows for Macros, C-functions and Assembly functions.

If any assembly code is used directly it will be reported as an compliler error for undefined identifier etc.

Print this item

  Is rule 10.5 compliant with rule 10.3?
Posted by: rmgalles - 07-02-2006, 07:53 PM - Forum: 6.10 Arithmetic Type Conversions - Replies (3)

Rule 10.3 requires a \"complex expression\" of integer type only be explicitly cast to a NARROWER type.

Rule 10.5 requires that bitwise operator RESULT be immediately cast to the underlying type (NOT a NARROWER type).

Based on the discussion in 6.10.5, a shift-expression IS considered a \"complex expression\" such that rule 10.3 should apply to rule 10.5? If so, doesn't this cast back to the underlying type violate rule 10.3?

The primary motivation of this question is that I think rule 10.3 should prohibit an explicit cast to a WIDER type, rather than only allow a cast to a NARROWER type. This seems to fit better with 6.10.3's discussion under \"evaluation type confusion\" (p. 38), as well as 6.10.1's \"to change the type in which subsequent arithmetic operation is performed\" statement.

It might be preferred that an expression use the implicit conversion rather than explicitly casting to the underlying type -- but should explicitly casting to the underlying type be prohibited by rule 10.3? Sometimes, the cast to the underlying type may be the same as the actual (promoted) type of the expression, and other times the cast to the underlying type is a conversion of the promoted type back to the underlying type. This depends on the types and the implementation-defined sizeof(int).

Some examples:

(1) Should:
[code]U16 = (uint16_t)((uint16_t)U8

Print this item

  Rule 19.12 (# and ## operator) real issue?
Posted by: rmgalles - 06-02-2006, 10:16 PM - Forum: 6.19 Preprocessing Directives - Replies (6)

I recognize that \"The order in which # and ## operations are evaluated during macro substitution (6.10.3.2, 6.10.3.3).\" [ISO C 9899:1999 J.1 Unspecified behavior] is UNSPECIFIED behavior.

However, what is the real issue with the order of evaluation being unspecified? I realize that rule 19.13 goes even further than MISRA-C:1998 and advises that these operators not even be used at all. However, I'm wondering if someone can provide an example where the order of evaluation matters?

The only example I can think of is:

Code:
#define MYMACRO(a,b) # a ## b
MYMACRO(foo,bar)

Could produce (## evaluated first, then #):
Code:
\"foobar\"

or (# evaluated first, then ##):
Code:
\"foo\" bar

depending on the order of evaluation.

However, as long as ONLY # operators, or ONLY ## operators are used (i.e., # and ## operators are not BOTH used in the SAME macro), then I don't see a problem.

It is sometimes useful to use these operators more than once within a macro, particularly the ## operator:

Code:
#define MY_IDENTIFIER(a) PRE_##a##_SUF
MY_IDENTIFIER(foo)

Will always result in a new identifier:
Code:
PRE_foo_SUF

It doesn't matter which ## operator executes first:
Code:
PRE_##foo##_SUF -> PRE_foo##_SUF -> PRE_foo_SUF
PRE_##foo##_SUF -> PRE_##foo_SUF -> PRE_foo_SUF

Both result in the proper final identifier.

Macros can then be used to replace otherwise \"copy-and-paste\" code with a single macro. Then, changes to the repetitive code can be made in a single location (the macro) rather than duplicated across several lines of code. This minimizes \"copy-and-paste\" errors in the original code creation, as well as \"copy-and-paste\" errors in code maintenance.

Granted, the use of such macros is not extremely common or widespread. However, it does have its practical uses, and when done may require more than one ## operator within a single macro.

I just wondered if a specific example is available that shows where the order of evaluation matters or could cause a problem based on the UNSPECIFIED behavior when only one TYPE of operator (# only, or ## only) is used in a macro, but the one operator may be used MORE THAN ONCE in the same macro.

If there is no such issue, could rule 19.12 be updated to:
\"Both # and ## operators shall not be used in the same macro definition.\"

Print this item

  Rule 12.6, effectively Boolean expressions in assignment?
Posted by: rmgalles - 03-02-2006, 09:29 PM - Forum: 6.12 Expressions - Replies (1)

The second sentence in Rule 12.6 says \"Expressions that are effectively Boolean should not be used as operands to operators other than (&&, || and !).\"

This makes sense for most operators, but what about the simple assignment operator?

Code:
bool a;

a = (b == c); /* is this allowed? */

Perhaps a disclaimer \"other than assignment\" could be added?

Print this item

  Rule 19.16
Posted by: nikunj - 02-02-2006, 09:04 AM - Forum: 6.19 Preprocessing Directives - Replies (2)

The syntax errors the rule talks about would any way be reflected as an sytax error by the compiler.

for example in
#defineNAME \"test\"

the complier would return an error.

So in effect the rule becomes redundant!

Print this item

  Rule 11.1 Interpretation
Posted by: nikunj - 02-02-2006, 08:59 AM - Forum: 6.11 Pointer Type Conversions - Replies (1)

Rule 11.1 says that, 'coversions shall not be performed between a pointer to a function and any other type other than an integral type'

what do the 'integral type' refer to?

Is there a violation in the following code:

int (*p)();
int *a;
p = a; /* is this a violation of Misra rule 11.1 ? */

Print this item

  Does 13.7 apply to ALL invariant Boolean expressions?
Posted by: rmgalles - 31-01-2006, 10:12 PM - Forum: 6.13 Control Statement Expressions - Replies (1)

The example only shows relational operators { < >= }.

What about other operators?
#define OPTION_ONE 0x01
#define OPTION_TWO 0x02

#define MY_OPTIONS (OPTION_ONE)
- or -
#define MY_OPTIONS (OPTION_TWO)
- or -
#define MY_OPTIONS (0x00)
- or -
#define MY_OPTIONS (OPTION_ONE | OPTION_TWO)


if ((MY_OPTIONS & OPTION_ONE) != 0) /* deviation from 13.7? */
{
...
}


In this case, equality operators { == != } are less likely to \"accidentally\" be always true/false (vs. intentionally always true/false), while relational operators can sometimes catch the programmer of guard (due to limited ranges of smaller integer types: [-128 to +127], [0 to +255], etc.


What about sub-expressions?
if ((u8

Print this item

  What operators are prohibited/allowed by rule 12.13?
Posted by: rmgalles - 31-01-2006, 08:37 PM - Forum: 6.12 Expressions - Replies (2)

The requirement text of rule 12.13 simply states ++ and -- \"should not be mixed with other operators in an expression\", but it doesn't qualify which operators. In the supporting text, the general \"operators\" term is qualified with \"in combination with other arithmetic operators\" but doesn't specify what the \"arithmetic operators\" are.

The simple example only seems to prohibit addition { + }, which would naturally extend to { + - * / % }, and it would be reasonable to include bitwise operators { ~ & ^ | > }.

I just want to understand how restrictive this rule is.

At a minimum, you would need to permit address and indirection operators as well as structure and union member operators:
{ * & [] . -> }, where * is the unary indirection operator (not multiply), and & is the unary address operator (not bitwise AND operator).

It would also be reasonable to use relational operators { < >= }
as well as equality operators { == != }.

However, is the simple assignment operator { = } allowed?

What about compound assignment operators?
{ += -= *= /= %= &= ^= |= = }

Which of the following examples are permitted under rule 12.13?
(1) (*p)++;
(2) a[i]++;
(3) my_struct.member++;
(4) my_struct_ptr->member++;

(5) a = b++;
(6) pop_value = buffer[--index];
(7) buffer[index++] = push_value;
(8) *p1++ = *p2++;

(9) do { ... } while ((i--) > 0);

(10) sum += buffer[i++];

My thoughts:
(1) to (4) DEFINITELY allowed (just using operators to reference correct object in memory to increment/decrement).

(5) to (8) SHOULD be allowed: common to use ++ -- in \"simple\" assignments to copy data between objects.

(9) COULD be allowed: while() or do-while() loops may sometimes be preferred over for() loops.

(10) likely NOT allowed, as:
E1 = E2
is just shorthand syntax for:
E1 = E1 (E2)
for all the compound assignment operators.

So, any code using any of these (binary) operators would be discouraged:
{ + - * / % & ^ | > }

What about unary operators:
{ + - ~ }

Just for reference, QAC (6.0.1) with MISRA-C:2004 compliance module M2CM (v1.1) interprets rule 12.13 as a violation with the QAC rule:
3440 Result of ++ or -- operator used in expression.

Thus, it only allows (1) to (4), and prohibits the other forms.
Is QAC's interpretation correct? Or, are more variations allowed?

My concern is an interpretation that is too restrictive will encourage users to always take exception to the rule (i.e., disable the static analysis rule check), rather than having a rule that pinpoints examples that would likely result in a software defect (which would discourage disabling the rule).

This could be split into two rules, one that prohibits ++ and -- used with any of the following operators:
{ + - * / % ~ & ^ | > }

And another that prohibits using the result of ++ or -- operator in an expression.

This provides a two-stage filter, one that catches the more \"serious\" issue, and a more conservative filter that prohibits rather benign code.

Print this item

  static function prototype
Posted by: bpereira - 11-01-2006, 09:32 AM - Forum: 6.8 Declarations and Definitions - Replies (2)

The specification isn't clear about static function, should they have prototype or not ?

The rule talk about declaration in header file, of course this isn't applicable to static function. So it sound to me that static function should not have prototype.

Print this item

Search Forums

(Advanced Search)

Forum Statistics
» Members: 6,121
» Latest member: Alain.Djempe
» Forum threads: 968
» Forum posts: 2,657

Full Statistics

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

Latest Threads
A13-5-4 opposite operator...
Forum: AUTOSAR C++:2014 rules
Last Post: aromauld
26-04-2024, 03:34 PM
» Replies: 0
» Views: 66
C++17 [[fallthrough]]; at...
Forum: 6.6 Statements (C++)
Last Post: mshawa
22-04-2024, 06:29 PM
» Replies: 0
» Views: 73
cvalue and constant integ...
Forum: AUTOSAR C++:2014 rules
Last Post: misra cpp
19-04-2024, 04:53 PM
» Replies: 1
» Views: 231
Rule 6-2-3 and C++17 [[fa...
Forum: 6.6 Statements (C++)
Last Post: misra cpp
19-04-2024, 04:48 PM
» Replies: 1
» Views: 203
10.2.3 Amplification
Forum: 4.10 Declarations
Last Post: misra cpp
12-04-2024, 02:20 PM
» Replies: 1
» Views: 239
Rule 7.0.5 Example potent...
Forum: 4.7 Standard conversions
Last Post: misra cpp
12-04-2024, 01:54 PM
» Replies: 1
» Views: 184
Rule 0.2.4 non-compliant ...
Forum: 4.0 Language independent issues
Last Post: misra cpp
12-04-2024, 01:51 PM
» Replies: 1
» Views: 217
Further guidance on MISRA...
Forum: 8.10 The essential type model
Last Post: mshawa
09-04-2024, 02:29 PM
» Replies: 0
» Views: 134
MISRA AC SLSF:2023 AMD1
Forum: MISRA AC resources
Last Post: david ward
05-04-2024, 01:56 PM
» Replies: 0
» Views: 153
MISRA AC GMG:2023 release...
Forum: MISRA AC GMG discussions
Last Post: misra-ac
25-03-2024, 06:01 PM
» Replies: 2
» Views: 533