4 Dec
2014
4 Dec
'14
11:12 a.m.
On Dec 4, 2014, at 10:59 AM, Chuck Guzis <cclist at
sydex.com> wrote:
On 12/04/2014 09:52 AM, Fred Cisin wrote:
To add to this. In a couple of places I was "forced" to use static analysis
tools to "check" my code.
This was usually required before a check-in. The problem with the analysis tools is
that:
(a) they didn't understand the kernel environment that I was working in (see
Chuck's earlier comment)
(b) they didn't understand (or weren't sophisticated enough) to understand that
certain conditions were
*can't* happen conditions but the tool would throw errors which in order to
remove (the errors) code
needed to be added that induced code-bloat and performance reductions.
In the end, enough of us "kernel hacks" got management to relent and not require
the tool to be run on
kernel code. We just ran with all error checks enabled in the standard compiler.
TTFN - Guy
Is C more dangerous than Assembly?
No, it isn't--it does, however, lack a good macro facility. Sadly, good macro
facilities for assemblers have been going out of style. Witness the assemblers for modern
MCUs. It's pretty much assumed that these will be programmed in C--that's what
the tool suite is written in and it's expected that this is what people will use. An
assembler is done because it's customary.
Viewed as a low-level implementation language a step above assembly, run-time error
checking is ridiculous. What do you do in an OS kernel when an exception is thrown
because of a coding error? You die--maybe with some diagnostic information. Very often,
there's no way forward.
What a OS kernel programmer worries about is unexpected behavior of physical devices.
What do you do if a device dies in the middle of an operation? What if a device simply
misbehaves? Easy--you detect it and die.
BSODs, DEADBEEF errors, you name it.
You try to be as careful as you can be, coding correctly. If you can get a buffer
overrun, you should be checking for it. If you try to page out the resident pager code,
you did something wrong and no runtime error checking is going to fix that.
C is a chainsaw, as others have said. So is assembly. Trying to change it into a
screwdriver is a hopeless task. Just the idea of unrestricted pointers makes good
run-time diagnosis hopeless and is the bane of automatic compile-time optimization.
I am in favor of very good compile-time diagnostics, no matter the language, however.
Getting 150 error messages because you forgot to close a brace somewhere is just stupid.