C, please die, and take Go with you - Re: Fwd: is there any word processing software for the pdp11?

[Guy Sotomayor]

> 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:
> 
>> 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.

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