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

Username
  

Password
  





  1-bit bitfield in boolean expression
Posted by: holger_l - 22-07-2013, 08:53 AM - Forum: 6.13 Control Statement Expressions - Replies (2)

Hi,
rule 13.2 makes an example how boolean data could be used in an expression:

Code:
if ( y ) /* Not compliant, unless y is effectively Boolean data (e.g. a flag) */
The example refers to a Boolean-by-enforcement type referred to in the appendix.
But what is with a 1-bit Bitfield? Is it a Boolean-by-construct?
Code:
struct { unsigned int flag1: 1, flag2: 1;} var;
...
if (var.flag1)                   /* violation of rule 13.2 ? */
if (( var.flag1) && (var.flag2)) /* violation of rule 12.6 ? */
if ((!var.flag1) && (var.flag2)) /* 2x violation of rule 12.6 ? */
if ((var.flag1 == 0) && (var.flag2 != 0)) /* OK, but clumsy and harder to read */
Thanks for a comment!

Print this item

  Conditional stream opening and 22.3?
Posted by: gs - 12-07-2013, 04:05 PM - Forum: 8.22 Resources - Replies (1)

Does the rule prohibit cases like the following:

Code:
if( someCondition )
    f = fopen( "apple", "r+" );
else
    f = fopen( "apple", "r" );
g = fopen( "apple", "r+" );

Print this item

  Essential Type Category of Complex Floating Types?
Posted by: gs - 27-06-2013, 05:11 PM - Forum: 8.10 The essential type model - Replies (2)

C99 provides for complex floating point types. What is the essential type category of each?

Print this item

  Floating point test for equality
Posted by: richardb - 26-06-2013, 11:16 AM - Forum: 8.10 The essential type model - Replies (2)

The previous MISRA version (2004) explicitly banned the use of tests for equality on floating point numbers (MISRA C 2004 rule 13.3).
MISRA C:2012 has a list of operands and essential types to avoid in the table in rule 10.1, but the use of the equality operator, ==, on the essential type floating is not restricted.
Could I suggest this is an unintentional omission?
Richard.

Print this item

  Rules 13.4 Function call with float
Posted by: Bfr - 25-06-2013, 02:34 PM - Forum: 6.13 Control Statement Expressions - Replies (1)

Hello,

As the rule 13.4 says : The controlling expression of a for statement shall not contain any objects of floating type.

But what about a function call with a float as parameter (example below) ?

I am asking this in order to implement a MISRA rule checker.

Code:
int32_t i = 0;
float32_t float_var;

[...]

for (i = 0; i < float_to_int(float_var); ++i)
{
[...]
}

It seems correct to me since the float is not really use in the controlling expression. But the rules says any objects and that confuse me a little.

Thanks,
Ben

Print this item

  Example for Rule8.10 (inline function)
Posted by: Wolfgang Gebauer - 20-06-2013, 09:35 AM - Forum: 8.8 Declarations and defnitions - Replies (1)

Hello,

I have a question regarding the Rule 8.10.
Usually in our code we implement inline functions in header files.
Therefore these inline functions are already visible in many modules.
How can these inline function be made static?
Is it necessary to implement these inline functions as static in header files?
example:

header_file.h
inline void function1(int a, int b)
{
...
return;
}

c_file1.c
include
void function3(void)
{
function1(a_param, b_param);
...
return;
}

Can somebody give me a solution?

Regards
Wolfgang

Print this item

  Rule 19.4 do-while(0) for single statements
Posted by: wwinzer - 28-05-2013, 06:24 AM - Forum: 6.19 Preprocessing Directives - Replies (2)

While I fully understand the need to weld multiple statements in a function-like macro into a compound statement using the do-while(0) construct, I wonder why rule 19.4 explicitely includes macros with only one statement.

Quote: The do-while-zero construct is used to wrap a series of one or more statements and ensure correct behaviour.

I've searched the net high and low and could not find any reason for requiring single statements to be encapsulated in do-while(0). Could you give an example here of code that breaks when disregarding this rule?

Print this item

  8.14 and "involved in a decision to exit the loop"
Posted by: gs - 01-05-2013, 02:23 PM - Forum: 8.14 Control statement expressions - Replies (1)

Section 8.14 defines a loop counter as "an object, array element or member of a structure or union which"

  • 1. has scalar type,
    2. varies monotonically on each iteration of a given instance of a loop, and
    3. is involved in a decision to exit the loop.
My question is, "To what extent does the item in question need to be "involved in a decision to exit the loop"? For example, consider the code:
Code:
...
if( g(x) )
    break;
...
Is 'x' "involved in a decision to exit the loop"?

What of
Code:
...
if( h() )
    break;
...
where 'h()' returns a value based on, say, a static variable, 'q'; is 'q' "involved in a decision to exit the loop"?

Print this item

  Appendix B - mapping of rule 10.2
Posted by: andream - 23-04-2013, 09:41 AM - Forum: 6.10 Arithmetic Type Conversions - Replies (1)

It seems there is a minor inconsistency in MISRA-C 2004. At top of pag. 103 (Appendix B) I can read that rule 77 in MISRA-C 1998 is mapped onto rule 10.2 in MISRA-C 2004. Indeed this latter is as duly reported in third column ("The value of an expression of floating type..."), but corresponding rule 77 in MISRA C 1998 is well different:

"The unqualifed type of parameters passed to a function shall be compatible with the unqualified expected types defined in the function prototype".

Can you help me?

Print this item

  For rule 5-2-12: replace "variable" with "value"?
Posted by: James Widman - 12-04-2013, 05:04 PM - Forum: 6.5 Expressions (C++) - Replies (5)

Rule 5-2-12 is: "An identifier with array type passed as a function argument shall not decay to a pointer."

Why does the rule apply only to identifiers and function arguments? Example:

Code:
typedef char S[10];
S& f(void);
void g( const char * );
struct A { S m; };
A i(void);

void h(void) {
    g("foo");   // Compliant with the letter of 5-2-12.
    g(f());     // Compliant with the letter of 5-2-12.
    g(i().m);   // Compliant with the letter of 5-2-12.
}

Each of these calls would be in violation if the rule applied to values rather than variables.

Also the rationale says, "If a design requires arrays of different lengths, then a class should be used to encapsulate the array objects and so ensure that the dimensionality is maintained."

This question was motivated by a test case from one of our users:

Code:
#include

void dummy() {
    std::string s;
    s.assign("Hallo");
}

... against which PC-lint, in MISRA C++ mode, says that rule 5-2-12 has been violated. That's incorrect according to the letter of 5-2-12, but then, 5-2-12 is apparently violated in:

Code:
#include

void dummy() {
    const char h[] = "Hallo";
    std::string s;
    s.assign(h);
}

But given the rationale of the rule, it seems like MISRA probably wants to make an exception for the case of std::basic_string::assign(const char*) because it converts from a null-terminated character array to an object of class type that encapsulates the array value.

What about the restriction to cases of function arguments? Why does this restriction not apply to other contexts where there is a decay from array to pointer type? (Think of initialization/assignment in the context of a return statement, in the definition of a variable, in a curly-braced initializer, or in a men-initializer.)

If this rule applies only to function arguments but not initializers, then there is a funny difference in the treatment of initializers: If a class object is initialized by a constructor that takes a pointer, then this rule applies when the initializer value is initially of array type (because a constructor is a function and the initializer value is the argument to that function). But if you change the type of the declared object to a bare pointer type, the rule does not apply.

Print this item

Search Forums

(Advanced Search)

Forum Statistics
» Members: 6,208
» Latest member: jablodan
» Forum threads: 1,017
» Forum posts: 2,796

Full Statistics

Online Users
There are currently 102 online users.
» 0 Member(s) | 99 Guest(s)
Bing, Google, UptimeRobot

Latest Threads
Rule 7.0.5, example non-c...
Forum: 4.7 Standard conversions
Last Post: cgpzs
17-04-2025, 12:10 PM
» Replies: 0
» Views: 182
A3-3-2 Contradictory exam...
Forum: AUTOSAR C++:2014 rules
Last Post: cgpzs
31-03-2025, 09:30 AM
» Replies: 2
» Views: 310
16.6.1 clarification
Forum: 4.16 Overloading
Last Post: cgpzs
31-03-2025, 09:29 AM
» Replies: 2
» Views: 296
Rule 9.3.1 - iteration st...
Forum: 4.9 Statements
Last Post: misra cpp
28-03-2025, 01:17 PM
» Replies: 1
» Views: 195
Rule 8.2.8 - why aren't a...
Forum: 4.8 Expressions
Last Post: misra cpp
28-03-2025, 01:05 PM
» Replies: 1
» Views: 214
Typo in Appendix C of MIS...
Forum: 8.10 The essential type model
Last Post: Yordan Naydenov
17-03-2025, 02:58 PM
» Replies: 0
» Views: 178
Adopted modal expressions...
Forum: General Questions
Last Post: Yordan Naydenov
17-03-2025, 09:01 AM
» Replies: 0
» Views: 281
Roadmap to c23 support
Forum: General Questions
Last Post: ACHart
28-02-2025, 03:23 PM
» Replies: 0
» Views: 220
Rule 6.2.1 weak linkage
Forum: 4.6 Basic concepts
Last Post: misra cpp
28-02-2025, 01:04 PM
» Replies: 1
» Views: 278
A8-4-5: Should have an ex...
Forum: AUTOSAR C++:2014 rules
Last Post: misra cpp
21-02-2025, 12:58 PM
» Replies: 3
» Views: 702