Re: [avr-gcc-list] Re: C vs. assembly performance

[Bob Paddock]

>> Note that technically no AVR-LibC based project complies
>> with MISRA due to rule #3.6 that says any library used,
>> including the GCC libraries, must be complaint with MISRA [IEC 61508
>> Part 3].  I tend to follow the MISRA Guidelines anyway as it shows an
>> attempt at Due Diligence.

> s/complaint/compliant/g
> They're two different words. ;-)

You should see a message that I've not proof read several times.
http://www.unusualresearch.com/spelling/spell.htm

> I would really like gcc to have a -wmisra switch someday, so we can test if 
> an >application, or library such as avr-libc is compliant.

Would be nice.  There are probably legal issues with doing that.
MISRA is one of those things you must buy.  There are not Open Source
versions, as MISRA does not allow the distribution of the rules without
proper licensing.

> Not that I like MISRA anyway. I think it's a brain-dead standard.

Most standards are that way, that is why they are standards.  Do you
have one you
like better?  To my knowledge after MISRA they get even harder to comply with,
like DO-178D.

> But do you have some tool that you have used to check avr-libc against MISRA? 
> If so, >do you have a list of issues that it found?

I use Gimpel's Lint: http://www.gimpel.com/html/misra.htm
to comply with rule 21.1-A; "use static analysis".

Take a look at the MISRA files near the bottom here:

http://gimpel.com/html/ptch90.htm#aulnt

MISRA being a 'C' standard doesn't help a lot with "hand optimized assembly"
in AVR-LibC.  Distributing the output of Gimpel's Lint is an other licensing can
of worms.  I'll see what I can come up with.

MISRA aside I think everyone should invest in their own copy of Lint,
especially people new to the language.  One of the few tools priced within
the range of an individual.  There is the Open Source Splint:
http://www.splint.org/ , however I'm not very familiar with it.

After a while you get to the point of writing your code where you end up with
a dialog going on in your head: "Lint is going to complain about that, do
it this way instead".  For example while(1){} per Lint and MISRA 13.7,
should be for(;;){} to prevent "constant value Boolean" error.

Making a game out of it, "Can I beat Lint today" by writing
code that Lint has noting to say anything about, takes the tedium
out of using the tool.  If your new to Lint, then turn up the error
level slowly, or you will
run away screaming when you see your first output run.

Event Lint doesn't help with some issues, like having a missing 'extern' to
a linker implied symbol that compiles ok with CAN64, but produces
funky outputs with Tiny88.  Those types of issues are why MISRA wants
all of the compiler validated.