Welcome to the MISRA discussion forum

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.)

My question is if there are one or more errors in this code?????????

Dear Misra

I seek clarification on the particular meaning of this rule. From the rule statment I take it that everything declared at file scope and only used internally should have the static storage class specifier applied.

For example the following would be a violation, ignoring the violation of rule 8.7.

Hi,

MISRAC 2004 Rule 1.1 refers to the environment limits specified in section 5.2.4 of the ISO 9899:1990 standard.

According to this rule, should all the limits specified by this section be STRICTLY followed, or only the one limit on internal and extrenal identifier length be strictly followed (Rule 5.1). Is a piece of code having 128 nesting levels of blocks MISRAC compliant?

Also there is a mention of the need to have certain compiler extentions in the code. Is a piece of code, having certain compiler extentions MISRA compliant? Or is it upto the organisation to decide that?

Best Regards
Vkmet

mda5tbl[] = { (u8)5,
(u8)9,
(void*)wsrid00 --> Warning No. 307 };

static void wsrid00(void)
{
u16 i;
wmsgo[4] = 0;
for(i=0; i