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

Username
  

Password
  





  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

  Silencing the checker
Posted by: JonM - 08-02-2009, 08:35 AM - Forum: 6.2 Language Extensions - Replies (4)

What do people think of comments like these in code

/* defines to satisfy the MISRA checker tool */
... inevitable strange pre-processor magic


#if defined ( MISRA_CHECK )
.. behaviour 1
#endif

I see worrying amounts of it in a project I am working with and it makes me think I am working with unfinished code where the developers would rather continue writing insecure code by keeping a checker quiet than addressing the root causes. That this has been allowed by the checking tool vendor without

Does this kind of thing satisfy the spirit of MISRA and should checking tool vendors be inventing their own suppression language to litter the C-code with?

Does it break rule 2.4 - sections of code should not be commented out

Could we have a rule that bans checking tool logic, defines and comments in production code. Could we add a rule that requires checking tool vendors be required to discard the content of all well formed comments and not add mechansims for the programmer to determine if a checking tool is parsing the code? please.

Jonathan

Print this item

Search Forums

(Advanced Search)

Forum Statistics
» Members: 6,309
» Latest member: 1fuhd
» Forum threads: 1,066
» Forum posts: 2,933

Full Statistics

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

Latest Threads
13.2 Was TC2 correctly ap...
Forum: 8.13 Side effects
Last Post: misra-c
08-10-2026, 12:47 PM
» Replies: 1
» Views: 624
20.12 Does the stringific...
Forum: 8.20 Preprocessing directives
Last Post: misra-c
08-10-2026, 12:40 PM
» Replies: 1
» Views: 554
13.3 Should side effects ...
Forum: 8.13 Side effects
Last Post: misra-c
08-10-2026, 12:37 PM
» Replies: 1
» Views: 426
11.6 pointer to pointer t...
Forum: 8.11 Pointer type conversions
Last Post: misra-c
08-10-2026, 12:21 PM
» Replies: 2
» Views: 1,032
What is the UTLR of -1?
Forum: 8.10 The essential type model
Last Post: misra-c
08-10-2026, 12:15 PM
» Replies: 1
» Views: 597
10.3 Clarify if narrower ...
Forum: 8.10 The essential type model
Last Post: misra-c
08-10-2026, 11:57 AM
» Replies: 1
» Views: 508
It 8.12 intended to be so...
Forum: 8.8 Declarations and defnitions
Last Post: misra-c
08-10-2026, 11:50 AM
» Replies: 1
» Views: 455
Rule 0.1.1 Example f4
Forum: 4.0 Language independent issues
Last Post: cgpzs
07-10-2026, 11:07 AM
» Replies: 3
» Views: 721
Rule 6-2-2 Usage of std::...
Forum: 6.6 Statements (C++)
Last Post: misra cpp
25-09-2026, 05:43 PM
» Replies: 1
» Views: 436
M5-0-4 switch over unscop...
Forum: 6.5 Expressions (C++)
Last Post: misra cpp
25-09-2026, 01:00 PM
» Replies: 3
» Views: 533