4 Dec
2014
4 Dec
'14
10:59 a.m.
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.
--Chuck