On Sunday 13 December 2009, Carsten Breuer wrote:
> If i have time i will make a check with lint and QAC and
> if there are errors, i will submit patches.
Great! Though try to filter out any that aren't going
to be in the "obviously worth fixing" category and are
more in the "debatable style choice" side of things.
> 90% of the warnings reported are things that complain about "code style"
> like
> "use const wherever you can" or "reduce visibility only
> to the stuff that is really needed". We normally fix every warning,
> to get the code lint clean.
Most of those would be no problem at all to see fixed.
> > Note that MISRA is not universally lauded. As I understand, some of
> > its practices are contrary to other widely adopted coding policies.
>
> Sure. Some points are a laugh like "a null pointer should not be
> dereferenced".
That one touches on interesting system philosophy though. Should
one guard _every_ pointer access with an "if (ptr == NULL)" check?
I'm personally used to the answer to that being "no", and being
able to rely on inputs being non-NULL ... unless they're explicitly
stated as allowing NULL.
> Nonetheless, the code is IMHO at least better maintainable and more clear.
I'm not sure what you mean to imply by that NULL example, but the
two philosophies I'm aware of are:
- Having largely superfluous NULL checks obfuscates the code and
makes it less clear. If anyone wrongly passes a NULL, we get a
nice fast-fail that's easily tracked down and fixed. Plus, there
is a *LOT* of code (and runtime cycles) wasted on such checks.
versus
- Omitting such checks risks runtime failure that we can't ever
resolve once it gets in "the field". So checking is better
even though it slows things down and is largely pointless: you
can look at the code and know this failure won't happen.
and its variant
- Never use NULL. Always us a designated NOP object/instance
with an is_null() predicate.
Note that there are two different models of code maintainance there,
and two models of what "clear" means.
- Dave
_______________________________________________
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
