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

Username
  

Password
  





  Rule 45 and polymorphism
Posted by: jlb - 07-03-2007, 03:10 PM - Forum: 6.11 Pointer Type Conversions - Replies (3)

Hello,

I am new to MISRA-C rules and in the code I am working on, there this kind of constructs :

Code:
struct TPL_ACTION {
    tpl_action_func action;    /**<  action function pointer   */
};

typedef struct TPL_ACTION tpl_action;

and for instance :

Code:
struct TPL_TASK_ACTIVATION_ACTION {
    /*  base action           */
    tpl_action    b_desc;
    /*  task descriptor pointer     */
    tpl_task      *task;
};

typedef struct TPL_TASK_ACTIVATION_ACTION
tpl_task_activation_action ;

tpl_action is an abstract type (no instance) and tpl_task_activation_action is a concrete type.

The function pointed by action function pointer takes a tpl_action * and casts it to the appropriate concrete type.

I understand rule 45 disallows pointer type casting to avoid memory alignment problems but here the first member of the abstract type is of the same type as the first member of the concrete type.

Is it legal ?

Best regards

Print this item

  Casting a Float to a Signed Integer
Posted by: embedded.kyle - 05-03-2007, 10:04 PM - Forum: 6.10 Arithmetic Type Conversions - Replies (1)

I'm working with some legacy code and part of my job is to modify it to comply with the MISRA standard. A large portion of the code relies on macros such as this one:

[code]#define CURRENT_LARGE_SHIFT (18L)
#define CURRENT_LARGE_SCALE(v) (int32_t)(v * (1L

Print this item

  Other question about pointer to void
Posted by: fwamolina - 07-02-2007, 08:48 PM - Forum: 6.11 Pointer Type Conversions - Replies (1)

In misraC-2004 when starts section 6.11 - Pointer type Conversion says the following:

\"Conversions involving pointer types require an explicit cast except when:
The conversion is between a pointer to object an a pointer to void....\"

my question is if this example is compliance with that.

Code:
void func (void)
{
  void*          pt_V;
  uint8_t*       pt_A;
  uint32_t*      pt_B;

  .
  .
  .

  pt_V = pt_A;

  /* use pointer */

  pt_V = pt_B;

  /* use pointer */

  .
  .
  .
}

thank you.

Print this item

  Boolean Types
Posted by: djtachyon - 05-02-2007, 07:08 PM - Forum: 6.6 Types - Replies (1)

Just wondering what is the best way to define a boolean type for MISRA and most importantly what to define TRUE and FALSE as.

Some thoughts:

typedef unsigned char boolean_t
#define TRUE (0==0)
#define FALSE (!0)

Thanks.

Print this item

  MISRA C 2004 Compliance Matrix
Posted by: Anonymous - 11-01-2007, 09:32 AM - Forum: General Questions - Replies (1)

Is there a template of the required Compliance Matrix available?

I would like to see such a matrix include the rule synopsis as well as it's ID, so that it is easy to comprehend.

Having purchased the MISRA-C 2004 PDF, I find that it is protected such that I cannot copy the contents of Appendix A as a good starting point.

Regards
Dave Banham

Print this item

  Void Pointer Usage
Posted by: MikeS - 11-01-2007, 09:04 AM - Forum: 6.11 Pointer Type Conversions - Replies (1)

Hi,

I have a question regarding the use of Void pointers.

Rule 11.2 is the rule that applies (Conversions shall not be performed between a pointer to object and any type other than an integral type, another pointer to object or a pointer to void).

My first question is:
How do you define \"a pointer to object\"?
By this, do you mean structure, derived types?
I couldn't see any definition for this in the MISRA text.

My second question is:
This rule allows the conversion of a pointer from one type to void. (i.e. to a NULL_PTR to allow for error checking)
I think that this rule also prohibits the use of a defined void ptr, converting this to point to an array or other obect, is this correct?

i.e. the following is illegal:

void *pv_my_void_ptr = NULL_PTR;
u16 *pu16_my_int_ptr = (u16 *)pv_my_void_ptr;

As this would make the checking of alignment (i.e. Rule 11.4) impossible as well as hiding the original type pointed to?

Many Thanks for your consideration.

Mike.

Print this item

  Complementary documentation on MISRA Rules
Posted by: Nicolette MAZURIER - 11-12-2006, 11:07 AM - Forum: General Questions - No Replies

I am working as a Software Quality Engineer at Siemens VDO in France and we are currently trying to document the consequence(s) of not respecting each of the MISRA rules, in order to make our developers aware of the risk(s). Sometimes this task is quite easy and sometimes less. So I am looking for some documentation that could help us reaching our objective. Today we are still using MISRA 1998, so I am more interested in documents dealing with the correponding rules, but it would also help for the future if some documents on MISRA 2004 exist.

Thanks for Help,

NM

Print this item

  MISRA Autocode Public Review
Posted by: david ward - 08-12-2006, 12:17 PM - Forum: Announcements - No Replies

MISRA has been developing a set of guidelines for users of control system modelling packages. The aim of the guidelines is to provide a set of rules, in a similar fashion to the MISRA C rules, which encourage good modelling practices and avoid poorly-defined features of the modelling language. In light of automotive industry trends, some rules will be aimed at the use of automatic code generators in safety-related systems.

Following the initial activities of this Working Group, MISRA is pleased to announce that drafts of the first documents will be available in the new year for public comment. These documents are:

  • MISRA SLSF - guidelines for users of Simulink and Stateflow
  • MISRA TL - guidelines for users of Targetlink
  • MISRA ACG - guidelines for compliance with MISRA C in automatically-generated code
If you are prepared to receive one or more of these documents for review, please visit the MISRA website to download a reply form and return by post or fax to MIRA. As this form requires a signature to indicate acceptance of the terms, only fully completed and signed copies can be accepted.

Print this item

  MISRAC Rules
Posted by: prabhakarp - 21-11-2006, 10:51 AM - Forum: MISRA-C:1998 to MISRA-C:2004 migration - No Replies

hello all,

can you anyone provide me some documents related to MISRA C rules

thanks

Print this item

  Underlying type of character constants and \"plain char
Posted by: Shane Swenson - 15-11-2006, 12:40 AM - Forum: 6.10 Arithmetic Type Conversions - Replies (4)

We're wondering if rule 10.1 applies to character constants and the \"plain char\" type, and, if so, what their underlying types are. For example,

Code:
char_t c1 = 'a';
char_t c2 = 'abc';
From the discussion in 6.10.4, we expect that the underlying types of 'a' and 'abc' are 8 bit signed and 32 bit signed, respectively, on a target with 8 bit chars.

The underlying types of c1 and c2 are less clear. We could treat \"plain char\" similarly to signed char or unsigned char based on the implementation's signedness of \"plain char\", or from the discussion following rules 6.1 and 6.2, we could deduce that \"plain char\" is distinct from signed char and unsigned char with respect to rule 10.1.

If rule 10.1 applies to character constants, we expect that the assignment to c2 violates rule 10.1 because it probably requires a conversion of the character constant to a narrower type. If the \"plain char\" type is unsigned on the target system, the assignment to c1 could be considered as violating rule 10.1 because it requires a conversion from a signed type to an unsigned type.

If the \"plain char\" type is considered distinct from the signed char and unsigned char types, both assignments would violate rule 10.1 unless the underlying type of a character constant is also \"plain char\", though this also seems problematic since, for example, the plain char type usually can't represent the value 'abc'.

What are the Committee's positions on these issues?

Print this item

Search Forums

(Advanced Search)

Forum Statistics
» Members: 6,215
» Latest member: minseow
» Forum threads: 1,017
» Forum posts: 2,796

Full Statistics

Online Users
There are currently 175 online users.
» 0 Member(s) | 171 Guest(s)
Bing, DuckDuckGo, 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: 192
A3-3-2 Contradictory exam...
Forum: AUTOSAR C++:2014 rules
Last Post: cgpzs
31-03-2025, 09:30 AM
» Replies: 2
» Views: 328
16.6.1 clarification
Forum: 4.16 Overloading
Last Post: cgpzs
31-03-2025, 09:29 AM
» Replies: 2
» Views: 312
Rule 9.3.1 - iteration st...
Forum: 4.9 Statements
Last Post: misra cpp
28-03-2025, 01:17 PM
» Replies: 1
» Views: 201
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: 225
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: 188
Adopted modal expressions...
Forum: General Questions
Last Post: Yordan Naydenov
17-03-2025, 09:01 AM
» Replies: 0
» Views: 298
Roadmap to c23 support
Forum: General Questions
Last Post: ACHart
28-02-2025, 03:23 PM
» Replies: 0
» Views: 225
Rule 6.2.1 weak linkage
Forum: 4.6 Basic concepts
Last Post: misra cpp
28-02-2025, 01:04 PM
» Replies: 1
» Views: 286
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: 734