MISRA-C

"You can write perfectly awful code even (or "especially") when following the MISRA rules religiously."

Indeed, quite awful code. There has been a length thread in comp.arch.embedded on this topic:

groups.google.com/.../492cec375ac59ba3

"You can write perfectly awful code even (or "especially") when following the MISRA rules religiously."

Indeed, quite awful code. There has been a length thread in comp.arch.embedded on this topic:

groups.google.com/.../492cec375ac59ba3

Hi,

its me, the bullshit man again ;-).

I really think that MISRA is more academic but not for professionals. i have a lot of yars experience in professional development of embedded devicec in very very big projects.
I dont need a kindergarden-guidance like MISRA. one rule is "dont use nonstandard language extensions". this is simply not possible in reality, like many more rules.

understand me right, i am not against guidancees, but MISRA is one of the badest i have ever seen.

please you should be writing message good like thiis firstly and say reeson is nice yes

i thinking you not bigot now ;)

"one rule is "dont use nonstandard language extensions"."

So for example, when using Keil C51 plus MISRA-C guidelines, one is limited to the memory models selectable at the toolchain level and can't mix; that is, use a predominantly small model with xdata-qualified objects where needed?

Come to think of it now, one couldn't access SFRs either due to the way they are defined in the header files, right?

Does anybody use C51 plus MISRA-C guidelines?

MISRA C--A set of guidelines meant to stifle the artistic freedom of fun-loving C developers worldwide.

extracted from "

one is limited to the memory models selectable at the toolchain level and can't mix;

That's what that rule says, yes.

Does anybody use C51 plus MISRA-C guidelines?

I feel really sorry for anyone who has to do this.

There are 'rules' in MISRA C that makes for better software

Of course. And of course those can be found in any book about good coding practices, along with the cases when it might make sense to break them (for example the "Goto must not be used." rule).

(for example the "Goto must not be used." rule).

that rule is broken "every day by everybody"

What is a switch statement but a bunch of "if - goto" statements?

HOWEVER, the C 'structure' does not lend itself very well to the implemetation of GOTO, so, thinking of it I have no assembler that is not full of GOTO and no C that has any.

Erik

that rule is broken "every day by everybody"<p>

If you want to write code in compliance with MISRA-C rules, you better not break that rule, or your code will not comply with the standard anymore.

Same thing goes for using a break; statement outside a switch/case structure, using a continue; statement, or using more than one return statement in a function.

"Same thing goes for using a break; statement outside a switch/case structure, using a continue; statement, or using more than one return statement in a function."

Oops! Bad Dan. Bad, bad Dan!

that rule is broken that rule is broken "every day by everybody"<p>

If you want to write code in compliance with MISRA-C rules, you better not break that rule, or your code will not comply with the standard anymore.

I did not say anything about that an actual GOTO statement was used "every day by everybody", what I said is that a switch statement is the equivalent of (if - goto) and thus if you use a switch statement (which MISRA allows) you are in fact using GOTOs.

Erik

"a switch statement is the equivalent of (if - goto)"

equiverlent of goto in 8051 is jmp yes

you be try writing assemblery with no jmp and yeou have only v little code you know

but docomenent is MISRA-C not MISRA-8051 so not good to say equiverelent switch if-goto

whot profffesional C coder do use goto????? i not know you know

i do not you thinking yes

goto really is useful in some situations.

However, all usage should be very similar to the usage of break and continue, but with the ability to make it multi-level, i.e. to break out of (or restart) more than one encapsulation.

You might have a function:

void fnk(void) {

restart:
    do_something();
    for (;;) {
        do_more();
        switch (x) {
            case 1:
                if (error) goto fail;
                do_work();
                break;
            case 10:
                do_even_more();
                break;
            default:
                goto restart;
        }
    }

fail:
    do_cleanup();
}

Yes, it is possible to solve all flow problems with flags, a large set of conditionals, and optional extra loops, but there comes a point where these flags gets very hard to read. The code must check if it should leave (or restart) first level, then second level, ...

I can not even imagine to apply each and every 'rule' in MISRA C but to state it is 'bullshit' is stating that every rule is 'wrong' which even you must admit is not true. There are 'rules' in MISRA C that makes for better software

Have you actually read the MISRA C guidelines?

"... but there comes a point where these flags gets very hard to read."

And thus become a potential source of errors themselves when the logic they control is not obvious.

Jack Sprat is a blabbering idiot that - without any such knowledge - claim to know what i do and do not do and I do not show such individuals diddlysquat.

Erik