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

Username
  

Password
  





  Packed struct
Posted by: jimhuf - 29-09-2011, 10:27 AM - Forum: 6.2 Language Extensions - Replies (1)

Hi
is packing of structures allowed within Misra C?

I only wish to use the structure to overlay a generic byte array, which is populated from an external interface serialy. However the structure has 7 bytes but without packing has 8.

What i want is to be able to index into the generic array as such

sCFG *ptr = &genericArray[0];

for(i=0u; i< 10u; i++){
ptr[i].CFG0 = 10u;
..etc..
}

But because without packing the struct is 1 byte larger, i will end up misaligned.
So basically can i pack my structure to acheive this goal?

Thank you

James

FYI
typedef struct{
u8 CFG0;
u8 CFG1;
u8 CFG2;
u8 CFG3;
u8 CFG4;
u8 CFG5;
u8 CFG6;
}sCFG ;

Print this item

  Multiple local initialsaions in a single line
Posted by: alon - 20-09-2011, 06:10 AM - Forum: 6.9 Initialisation - Replies (1)

Hello

dose a line of the form

Code:
int i=0,j=0,k,l;
considered a misuse of the comma operator.
meaning, the line is considered as composed of multiple statements in a single line.
if so then what about, just plain

Code:
int i,jk;

Thanks

-Alon

Print this item

  MISRA AC EC guidelines
Posted by: alexandru.mihal - 16-09-2011, 01:50 PM - Forum: MISRA AC SLSF discussions - Replies (4)

Hello,
Can you tell me if the document MISRA AC EC is available? I saw in the MISRA AC INT a picture in which this document is present.

Thanks,
Alexandru Mihal

Print this item

  Rule 19.14 - multiple defines
Posted by: JohnC - 15-09-2011, 05:55 PM - Forum: 6.19 Preprocessing Directives - Replies (1)

Is this permissible under rule 19.14?

Code:
#define X ((defined(Y)) || (defined(Z)))
#if X
...
#endif

JohnC.

Print this item

  Rule 14.3 and null macros
Posted by: JohnC - 14-09-2011, 07:20 AM - Forum: 6.14 Control Flow - Replies (1)

If a function is sometimes to be included and sometimes omitted, the classic solution is to define it like this:

Code:
#if FnIsWanted
  extern void Fn( void );
#else
  #define Fn( )
#endif

As already noted, this falls foul of rule 14.3, though primarily it is a breach of rule 19.4 (what a macro can be defined as).

I can get the the effect I want on my compiler without apparently breaching MISRA rules by using the following alternative:

Code:
#if FnIsWanted
  extern void Fn( void );
#else
  #define Fn( ) do{}while(0)
#endif

However, the body of this do-while is a null (compound) statement, so has my compiler missed a violation?

Print this item

  13.5 for() loops - does simplicity matter?
Posted by: JohnC - 13-09-2011, 07:51 AM - Forum: 6.13 Control Statement Expressions - Replies (1)

I have compiled the following code. The compiler accepts the first loop (ending at X) but rejects the other two (ending at X+2 and at X*2)

extern tUI16 X, Y;
void Fn( void )
{
tUI16 i;
for( i = 0u; i < X; i++ ) /* accepted */
{
Y += i;
}
for( i = 0u; i < (X + 2u); i++ ) /* rejected */
{
Y += i;
}
for( i = 0u; i < (X * 2u); i++ ) /* rejected */
{
Y += i;
}
}

The compiler suppliers say the compiler will accept the second expression if it is "a simple test" and that X+2 and X*2 do not pass this test. I feel this is being too restrictive for rule 13.5. Please may I have an opinion on this.

Thanks,

John

Print this item

  Rule 16.7
Posted by: misterb - 12-09-2011, 04:54 PM - Forum: 6.16 Functions - Replies (1)

Hello,

please look at the following code snippet:

Code:
struct testStruct {
  float32_t varFlt3[3][16];
};

static void f1(struct testStruct * const testStructData);
static void f2(float32_t in_Data[3][16]);

static void f1(struct testStruct * const testStructData)
{
  f2(testStructData->varFlt3);
}

static void f2(float32_t in_Data[3][16])
{
    uint32_t i = 0u;
    for(i = 0u; i < 16u; i++)
    {
      in_Data[0][i] = (float32_t)i;
    }
}

int32_t main(void)
{
  /* This struct should be modified */
  static struct testStruct test;
    f1(&test);
    return 0;
}

My compiler returns a MISRA C rule 16.7 checker error because f1() shall point to a const object. In my opinion, it can't be const, because, the object is modified by f2() inside f1(). The compiler can know this. So who is correct? The compiler vendor or me? If the compiler is correct, how can I overcome this problem? If I modify the parameter of f1() to const I'll get an error because f2() modifies the object, the pointer parameter points to.

Kind regards,

Michael

Print this item

  Rule 7.1 For Macro Arguments?
Posted by: gs - 12-09-2011, 02:16 PM - Forum: 6.7 Constants - Replies (1)

Hi,

Does rule 7.1, "Octal constants (other than zero) and octal escape sequences shall not be used", apply to function-like macro arguments? For example:

Code:
#define MACRO(a)    XYZ_##a

int MACRO(01);

Is the '01' argument to MACRO() a violation of this rule?

Print this item

  Doubts on underlying type of integer constant expressions.
Posted by: zaffanella - 04-09-2011, 07:26 PM - Forum: 6.5 Expressions (C++) - Replies (1)

We need a few clarifications about the computation of underlying types for constants according to MISRA-C++-2008.

Please note that the following questions, even though using concrete examples for clarity, are meant to be general; in particular, here we are not asking how the examples should be changed in order to make them compliant with MISRA C++.

Question 1:
Given the following context:

Code:
enum Colours { RED, BLUE, GREEN };
  static const Colours red = RED;
and assuming a deviation from rule 4-5-2, what is the underlying type and cvalue-ness of expressions
Code:
RED + 1
and
Code:
red + 1
?

In section 6.5.0 of MISRA C++ (page 59) it is said:
Quote: Additive operators
[...]
The result is a cvalue expression whose underlying type is as defined by the underlying type conversions.
The underlying type conversions (page 57) state that if one of the arguments has enum type then the expression has enum type. Therefore, both expressions should be cvalues having underlying type enum Colours.

However, both expressions are integer constant expressions according to the C++ standard and hence the MISRA C++ rule about the underlying type of constants (page 60) seems to be relevant too:

Quote:Constant expressions
The result is not a cvalue expression. The underlying type for a constant expression “e” with a value “v” will have the same signedness as “e”, and a magnitude given by the underlying type of a single integer-literal with the same value as “v”.
According to this rule, we should consider integer literals with the actual values of the expressions (i.e., 1), thereby obtaining non-cvalue expressions having underlying type signed char.

To summarize:
1a) we would like to know if the MISRA rule about constant expressions should be applied only to expressions whose MISRA underlying type (computed as if they were not constants) is "effectively" integral, i.e., different from bool, plain char and enum;
1b) if that is the case (i.e., if red + 1 has underlying type enum), then what about its cvalue-ness? Is red + 1 a cvalue or not?

Question 2:
What is the underlying type of expression
Code:
1L
?

In section 6.5.0 of MISRA C++ (page 58) it is said:
Quote:Literals
The underlying type of an integral literal is the smallest fundamental type of the appropriate sign required to store its value. For example, the underlying type of the literal 128 is S16. The result is not a cvalue.
So, the underlying type of 1L should be signed char.

Is this really meant to be different from the underlying type computed according to MISRA-C-2004? For instance, in the examples for rule 10.1 (page 43 of MISRA-C-2004) we have the following line:
Code:
u8a = 5UL;    /* not compliant */
which is suggesting that the underlying type of 5UL is unsigned long. Is the integer literal suffix L relevant only for MISRA C and not for MISRA C++? Once again, this turns out be become a question on the applicability of the rule about constant expressions.

To summarize: we would like to know if the MISRA rule about constant expressions should be applied only to expressions whose MISRA underlying type (computed as if they were not constants) is one of signed char, unsigned char, short, unsigned short, int, unsigned int, thereby disregarding the "big" integer types.


Question 3:
Assuming that the answer to the Question 2 above is that the underlying type of 1UL is unsigned long, what is the cvalue-ness of
Code:
-1UL
?

If 1UL has underlying type unsigned long, then the rule about constants has not been applied. Hence, the only relevant rule is the one about the unary operators. In section 6.5.0 of MISRA C++ (page 58) it is said:

Quote:Unary expressions
[...]
- cast-expression
The result is a cvalue expression whose underlying type is that of the cast-expression.
Therefore, -1UL is not a cvalue. Is this meant, or is it the case that any ICE expression (no matter if bool, char, enum or effectively integer) is not a cvalue?

Thanks in advance for any clarification.

Print this item

  Rule 16.9
Posted by: roberto - 26-08-2011, 08:40 PM - Forum: 6.16 Functions - Replies (1)

Please consider the following snippet:

Code:
static int foo1(void) {
  return 0;
}

static int foo2(void) {
  return 1;
}

int foo() {
  /* Is the following occurrence of `foo1' compliant wrt 16.9? */
  if (&(foo1) == &foo2)
    return 0;
  return 1;
}

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 227 online users.
» 0 Member(s) | 225 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: 335
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,873
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,704
Signal naming convention ...
Forum: MISRA AC SLSF discussions
Last Post: misra-ac
21-10-2024, 07:57 AM
» Replies: 1
» Views: 7,257
Rule 7.0.2: operator cons...
Forum: 4.7 Standard conversions
Last Post: karos
14-10-2024, 08:52 PM
» Replies: 2
» Views: 447