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

Username
  

Password
  





  Violation of Rule 11.4 or Rule 11.5?
Posted by: zaffanella - 06-03-2009, 09:36 AM - Forum: 6.11 Pointer Type Conversions - Replies (3)

In Section 6.11 of the MISRA-C:2004 document, after the specification of Rule 11.5, the following example is reported:

Code:
/* ... snip ... */
const uint16_t * *  ppci;     /* pointer to pointer to const */
uint16_t * *  ppi;
/* ... snip ... */
ppi = (uint16_t  * *)ppci;           /* Not compliant               */
In my understanding, this is not really a violation of the required Rule 11.5; rather, it is a violation of the advisory Rule 11.4, since the pointed-to types
(namely,
Code:
const uint16_t *
and
Code:
uint16_t *
)
are two different pointer (hence, object) types; in particular, they are unqualified types.

This is quite the same as saying that
Code:
struct S { const char* s; };
struct T { char* s; };
struct S* ps;
struct T* pt = (struct T*) ps;
is a violation of 11.4 rather than 11.5.

Is my interpretation correct?
Or is it the case that Rule 11.5 has to be interpreted recursively,
so that in the two examples above we would have violations for both 11.4 and 11.5?

Thanks,
Enea.

Print this item

  Clarification Needed on Rule 20.12
Posted by: vijayendra - 05-03-2009, 03:24 PM - Forum: 6.20 Standard Libraries - Replies (1)

Rule says not to use any functionality of and it is a Required rule.

How to use POSIX compliant timer APIs like timer_create, timer_settime etc is also defined in this header file?

Print this item

  Rule 17.4 and Rule 14.7
Posted by: Kdasari - 02-03-2009, 01:12 PM - Forum: 6.18 Structures and Unions - Replies (2)

Hi Folks,

We appreciate the MISRA-C compliance.

We are making our application code into the MISRA-C compliance and can you please clarify below questions.

1./Rule 14.7: This rule says that array indexing is only allowed for pointer arithmetic. We understand that if we manipulate the pointer we may end up some cases accessing the non existing memory but suppose even if we access through the index and index is beyond the size of array declaration here also we end accessing the non existing memory , We have the below code and I think it is safe away of using? Can you please let us know the motivation of this rule and how indexing can avoid the error? Also let us know that the below code is acceptable or not?

void awe_vecAbs(
const float * src,
int srcInc,
float * dst,
int dstInc,
int blockSize)
{
int i;

for (i = 0; i < blockSize; i++)
{
*dst = fabsf (*src);
src = src + srcInc;
dst = dst + dstInc;
}

)
2./ Rule 14.7 says that the function should have the only one single exit but in some cases it is very difficult to compliance with this especially when we check for the error concealment. Please have a look at below code we still can use if ,else conditions but we end up having more checks like this which will degrade the system performance, Can you please let us know what way we can do this in better and motivation of this Rule?
if (currentObject == NULL)
{
return (E_NOT_OBJECT_POINTER);
}
id = awe_fwGetClassType(currentObject);
if (!IsClassValid(id))
{
return (E_NOT_OBJECT_POINTER);
}
*pObject = currentObject->pNextInstance;
if (*pObject == NULL)
{
return (E_NO_MORE_IOPINS);
}
*pClassID = awe_fwGetClassType(*pObject);
return (0);


Best regards,
Kishore.

Print this item

  Why rule 18.1?
Posted by: exoson - 19-02-2009, 11:11 PM - Forum: 6.18 Structures and Unions - Replies (1)

Please help me understand the reason for rule 18.1. In the context of an "opaque pointer", one can properly make and use such a pointer to an incompletely typed structure. Having the full structure declaration is not needed. The committee has endorsed this in a previous post.

What coding practice is left that might cause a problem? If the type is incomplete, a compile error will result from any attempt to create an object of that type or refer to its members.

OK, but even so, why not require it? In header files, I like to code:
struct something; /* with a forward declaration, I can create pointers. */

void foo (struct something *pointerToSomething);

The prototype is valid even though "something" is of incomplete type. If the #including .c file does not need anything other than the pointer, why require #including yet another header merely to get the (unused) full declaration and satisfy the rule?

Print this item

  Doubt on rule 13.2
Posted by: roberto - 16-02-2009, 01:01 PM - Forum: 6.13 Control Statement Expressions - Replies (4)

One of the examples given for rule 13.2 is:

Code:
if ( y ) /* Not compliant, unless y is effectively Boolean data
                              (e.g. a flag) */

Would it still be not compliant if y is of pointer type?
In case it is compliant, should 13.2 be interpreted as to be applicable only to expressions of integral type?

Print this item

  Again on rule 11.2 and Exemplar Suite
Posted by: roberto - 14-02-2009, 03:57 PM - Forum: 6.11 Pointer Type Conversions - Replies (1)

I agree that one should not write code like

Code:
float32_1102 = ( float32_t ) void_ptr;           /* Not Compliant */
   float64_1102 = ( float64_t ) void_ptr;           /* Not Compliant */

However, my understanding is that those lines do not violate rule 11.2, even taking into account the clarification given in TC1.
Am I correct?
Thanks,

Roberto

P.S. I read the other thread on the forum, but the question was not answered. I saw that thread is locked, and I do not know what is the right way to resurrect a discussion. Please accept my apologies if opening another discussion is not appropriate.

Print this item

  Rule 11.1 and NULL defined as ((void*) 0)
Posted by: roberto - 14-02-2009, 02:02 PM - Forum: 6.11 Pointer Type Conversions - Replies (1)

Please consider the following test program:

Code:
#define NULL ((void*) 0)

struct super_block;
struct inode;

typedef int (*find_inode_t)(struct inode *, unsigned long, void *);


extern struct inode * iget4_locked(struct super_block *, unsigned long,
                   find_inode_t, void *);

static inline struct inode *iget(struct super_block *sb, unsigned long ino)
{
    struct inode *inode = iget4_locked(sb, ino, NULL, NULL);
    return inode;
}


My reading of rule 11.1 is that NULL (so defined, which is quite common) cannot be passed that way to iget4_locked(). However, since I see zillions of violations of this kind, I am caught by the doubt.
Many thanks,

Roberto

Print this item

  Rule 10.5, shift left operator example
Posted by: OscarWild - 12-02-2009, 08:29 AM - Forum: 6.10 Arithmetic Type Conversions - Replies (4)

While the issue about the ~ operator in rule 10.5 is obviously handled by an immediate cast, I've been wondering, what the immediate cast of a shift left (

Print this item

  Bitfields vs masks for SFRs
Posted by: TheDoctor - 11-02-2009, 04:51 PM - Forum: 6.6 Types - Replies (1)

Is there a MISRA preferred route for accessing individual bit(s) in an SFR in an embedded micro? In MISRA C1 Rule 110 stated that "unions shall not be used to access the sub-parts of larger data types" and in the explanatory text said that the preferred method was the use of unsigned integer types and masks. However in C2 the rule has changed to "no unions" and this particular recommendation doesn't seem to have made it into the text anywhere.

Notwithstanding rule 18.4, on a micro I am working with at present the compiler writer provides access in the header file to each SFR through a union which overlays both a bitfield structure for the SFR and an unsigned object covering the whole width of the SFR. So if I want to extract (say) a 12-bit A/D value from an SFR location that contains the result as well as some other info e.g. status bits I can access this either as ADCchan.B.RESULT (where RESULT is a bitfield 12 bits wide) or ADCchan.U & 0x00000fffU.

Print this item

  A signed bit field of 1 bit length is not useful
Posted by: JonM - 08-02-2009, 08:41 AM - Forum: 6.5 Identifiers - Replies (2)

Is it possible to improve Rule 6.5 "A signed bit field of 1 bit length is not useful". Unlike the other rules, this doesn't actually advise/recommend any behaviour or give any insight as to what compilers may or may not do when presented with this.

How about - following the same outline structure of the following rule 7.1, something like:

A signed bit field of 1 bit length is treated as ...

There is a danger of ...

They are problematic when ...

It is better not to use signed bit fields of 1 bit length use ...

Jonathan

Print this item

Search Forums

(Advanced Search)

Forum Statistics
» Members: 6,212
» Latest member: subratasarkar
» Forum threads: 1,017
» Forum posts: 2,796

Full Statistics

Online Users
There are currently 178 online users.
» 1 Member(s) | 174 Guest(s)
Bing, Google, UptimeRobot, sebresr

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: 186
A3-3-2 Contradictory exam...
Forum: AUTOSAR C++:2014 rules
Last Post: cgpzs
31-03-2025, 09:30 AM
» Replies: 2
» Views: 321
16.6.1 clarification
Forum: 4.16 Overloading
Last Post: cgpzs
31-03-2025, 09:29 AM
» Replies: 2
» Views: 303
Rule 9.3.1 - iteration st...
Forum: 4.9 Statements
Last Post: misra cpp
28-03-2025, 01:17 PM
» Replies: 1
» Views: 196
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: 218
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: 182
Adopted modal expressions...
Forum: General Questions
Last Post: Yordan Naydenov
17-03-2025, 09:01 AM
» Replies: 0
» Views: 287
Roadmap to c23 support
Forum: General Questions
Last Post: ACHart
28-02-2025, 03:23 PM
» Replies: 0
» Views: 222
Rule 6.2.1 weak linkage
Forum: 4.6 Basic concepts
Last Post: misra cpp
28-02-2025, 01:04 PM
» Replies: 1
» Views: 281
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: 726