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

Username
  

Password
  





  C versus C++
Posted by: VanceTunnicliffe - 10-03-2009, 11:27 AM - Forum: General Questions - Replies (2)

Hi,

We are looking to adopt the MISRA guidelines in our company to improve our coding standards. Most of our existing projects contain both C and C++ source files. We like to use the benefits that C++ offers for writing things like a menu system (user interface), where a well-defined class hierarchy can help with modularising our code. However, it is our opinion that C offers a better solution for medium-speed applications such as an LCD display driver (to actually display our C++ based menu system).

In this case, which MISRA standard should we adopt ? Do we use the MISRA C++:2008 guidelines for both our C++ and C source files or do we check C++ files against this standard and use the MISRA-C:2004 guidelines for our C source code ?

Regards,

Vance

Print this item

  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

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 259 online users.
» 0 Member(s) | 257 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: 36
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: 399
A8-4-5: are partial moves...
Forum: AUTOSAR C++:2014 rules
Last Post: misra cpp
22-10-2024, 02:03 PM
» Replies: 1
» Views: 339
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,875
MISRA AC EC guidelines
Forum: MISRA AC SLSF discussions
Last Post: misra-ac
21-10-2024, 08:21 AM
» Replies: 4
» Views: 15,523
News on future releases
Forum: MISRA AC SLSF discussions
Last Post: misra-ac
21-10-2024, 08:05 AM
» Replies: 1
» Views: 5,707
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: 449