> -----Original Message----- > From: > avr-gcc-list-bounces+eweddington=cso.atmel....@nongnu.org > [mailto:avr-gcc-list-bounces+eweddington=cso.atmel....@nongnu. > org] On Behalf Of Bob Paddock > Sent: Sunday, March 01, 2009 6:22 AM > To: avr-gcc-list@nongnu.org > Subject: Re: [avr-gcc-list] Re: C vs. assembly performance > > > And the first complies with coding standards like gnu and gcc, > > and maybe even others like misra etc. > > MISRA doesn't say a lot about style, that is how pretty > the code looks. It is implicit that ugly looking code > is bad, and probably buggy. If your code looks > like a IOCCC entry, your code would not be MISRA > complaint. > http://www.ioccc.org/ > > Per MISRA, in a nested if/else tree all brackets are required, and > there must be a final else{} as you showed. > > As far as I can tell MISRA-2004 is silent on a preference > between switch(), nested if/else() and function pointers. > Personally I prefer tables of function pointers. Makes > code looking like a threaded language like Forth at times. > In any case what can get hairy fast is conditionals containing > conditionals, which makes testing all execution paths problematic. > > 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.
Bob, s/complaint/compliant/g They're two different words. ;-) 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. Not that I like MISRA anyway. I think it's a brain-dead standard. 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? Eric _______________________________________________ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
