Welcome to the MISRA discussion forum

Theses both rules (11.4 and 11.5) prevents against bad casting between pointers.


In my understanding, these both rules are applicable for explicit and implicit cast: The problematic is the same for explicit or implicit cast.


The understanding of my MISRA-checker-tools is that these rules address only explicit cast (these rules give only explicit cast example, and anywhere implicit cast is mentioned).
And this pointer implicit cast is not covered by another MISRA rule (Rules 10.1 and 10.2 don't address pointers cast but only integer and float implicit casts.)

Could you confirm which understanding is the good one?

Thanks in advance.

With rule 11.2,

\"Conversions shall not be performed between a pointer to object and any type other than an integral type, another pointer to object type or a pointer to void\"

my understanding of the term

\"another pointer to object type\"

is, that for example code like

int* Source;
long* Target;
Target = (long*)Source;

doesn't violate this rule (but at least violates rule 11.4);
but our misra checker tool's interpretation of this rule is more like

\"another pointer to same object type\"

therefore it emits a misra violation for code structures like the one mentioned above.

To help me out, could you please tell me which interpretation is right?

Thanks in advance,
elmar

Please let me know \"How do we access an unnamed member of a structure\"?

Its quite natural to use bitfields as unnamed members of a structure especially for padding. But, how do we access those unnamed members. Do we have to increment the pointer to access it? if yes, please illustrate it with an example.

Hi,
12.4 prohibits side-effects on the right hand side of '&&' or '||'. What if, on the right hand side, I place a function with no side-effects, provided it returns, but which does contain side-effects if it does not return (e.g., an assertion which writes to a log file of some sort)? Is such a function allowed on the right hand side of the logical operators?

Hi,
I use 'inline' within my code. Not wanting to go into any details, let us just suffice it to say I feel sufficient reason exists for me to do so. Does 8.5 apply to inline functions? Does the use of 'inline' supercede the restriction of 0 function definitions per header?

Hello!

Rule 6.3 of MISRA-C lists the typedefs for uint64_t and int64_t, which I believe are not used anymore in the standard and should be disallowed by C90.

Can you confirm that uint64_t and int64_t datatypes are not allowed?


Best Regards

Michael

Quote:18.1 All structure or union types shall be complete at the end of a translation unit.
A complete declaration of the structure or union shall be included within any translation unit that refers to that structure.

Hello. I have some open qusetions on the forum and am also interested in some of the other open questions anout MISRA C: 2004.

I have heard that a TC will be written or already has been written to clarify some of these topics.

If possible it would be great if you could provide an estimated date that this will me made available.

Thanks a lot

Hi there,

when using a UML modelling tool, should (according to MISRA) the generated code be verified, e.g. with MISRA-C ?

My experience is, that generated code often violates MISRA-C rules
and in IMO this is not a major issue, as you have to \"trust\" you codegenerator anyway ;-)

I think a better approach is, to verify the MODEL (and not the code) with some sort of model-checking...

Will the UML-group of MISRA produce such rules to verify against models ?

any other opinions, experiences ?

kind regards,
Bernhard.

I'm confused by the difference between the two examples in these two rules. In R5.6 we're shown that it is ok to reuse the structure member identifier \"next\" since \"member names are less likely to be confused\", and in R5.7 we're shown that members of two different structure types cannot have the same name (\"speed\").

Is the intention that one deviates from R5.7 leaving R5.6 to catch the most important cases? If so that isn't very clear from the text.

(Overall I'd be surprised if anyone ever sticks to R5.7 since it means that every identifier in your program, even every local, has to differ from every other. That means no \"i\", \"j\", \"p\", \"speed\", \"rpm\", ..., \"index\", etc.)