C, please die, and take Go with you - Re: Fwd: is there any word processing software for the pdp11?
3 Dec
2014
3 Dec
'14
12:04 p.m.
From: Al Kossow <aek at bitsavers.org>
People traded safety for speed, and thanks to the net and cowboy
programming, that has turned out to be a bad decision.
Pshaw. C is only as unsafe
as you make it. It's not the language that
has caused, for example, Internet security issues - it's programmers
who refuse to learn well-known lessons like "always, always, *always*
bounds-check network-facing buffers *no matter what*" that give us
things like Heartbleed and any number of other overrun/underrun/etc.
vulnerabilities.
Blaming the language for the badness of bad programmers is like
blaming the chainsaw for the actions of some nitwit who decapitated
himself playing with one.
3 Dec
3 Dec
12:30 p.m.
On Wed, Dec 3, 2014 at 1:04 PM, John Ames <commodorejohn at gmail.com> wrote:
> From: Al Kossow <aek at bitsavers.org>
> People traded safety for speed, and thanks to the net and cowboy
> programming, that has turned out to be a bad decision.
Pshaw. C is only as unsafe as you make it. It's
not the language that
has caused, for example, Internet security issues - it's programmers
who refuse to learn well-known lessons like "always, always, *always*
bounds-check network-facing buffers *no matter what*" that give us
things like Heartbleed and any number of other overrun/underrun/etc.
vulnerabilities.
In other words, in C the programmer has to take positive action to
achieve bounds checking, which in some other languages can be
done with no special effort by the programmer.
That doesn't sound to me like "C is only as unsafe as you make it".
Rather, it sounds like "C is only as safe as you make it".
Your argument is that a sufficiently good programmer will always
write proper checks, etc. Reality doesn't bear that out.
Blaming the language for the badness of bad
programmers is like
blaming the chainsaw for the actions of some nitwit who decapitated
himself playing with one.
C is a chainsaw that is not supplied with any of the safety features of
a normal chainsaw. It is a chainsaw that would be unlawful to
sell in the US.
4 Dec
4 Dec
7:06 a.m.
On 12/3/2014 1:30 PM, Eric Smith wrote:
C is a chainsaw that is not supplied with any of the
safety features of
a normal chainsaw. It is a chainsaw that would be unlawful to
sell in the US.
More like the old chainsaw joke.
man: this chain saw don't cut trees.
sales man: BRUMMMMMMMMM - did you read the manual?
9:23 a.m.
I'm not sure why some people insist on bashing C because it can be
misused/abused. C is a tool for when you need to touch the metal. It's
just not what anyone should use to write applications. You don't do finish
carpentry with a chainsaw, and you don't cut down trees with a keyhole
saw. Yet there are people who craft wood sculptures with a chainsaw... and
you can write applications in C. But chainsaws and C are more unforgiving
of ignorance than hand saws and Python.
And Go looks like nothing more than Emerald rebaked. See,
http://www.emeraldprogramminglanguage.org/. -- Ian
On Thu, Dec 4, 2014 at 7:06 AM, ben <bfranchuk at jetnet.ab.ca> wrote:
On 12/3/2014 1:30 PM, Eric Smith wrote:
C is a chainsaw that is not supplied with any of the safety features of
--
Ian S. King, MSIS, MSCS
Ph.D. Candidate
The Information School
University of Washington
An optimist sees a glass half full. A pessimist sees it half empty. An
engineer sees it twice as large as it needs to be.
a normal chainsaw. It is a chainsaw that would
be unlawful to
sell in the US.
More like the old chainsaw joke.
man: this chain saw don't cut trees.
sales man: BRUMMMMMMMMM - did you read the manual?
9:52 a.m.
On 12/3/2014 1:30 PM, Eric Smith wrote:
C is a chainsaw that is not supplied with any of the
safety features of
a normal chainsaw. It is a chainsaw that would be unlawful to
sell in the US.
It is rare that I disagree with Eric.
Yes, C is a chainsaw. I can accept that metaphor.
Yes, many people use it inappropriately,
Yes, many of those people shouldn't be using it at all.
Yes, chainsaws are dangerous. So are motorcycles.
Some people ride motorcycles inappropriately, and indeed, some shouldn't
even consider one. Some ride motorcycles for the wrong reasons, such as
inability to afford a car.
But consider the Joan Claybrook attempt at guvmint intervention, with her
NHTSA attempts to design a "safer motorcycle". C lets you put in
safeguards where you consider them necessary, and leave them out when
they are unnecessary and an inordinate hindrance. Unfortunately, many
programmers are not responsible in making that decision.
Is C more dangerous than Assembly?
C was the first "high level" language that I used that was easy to shove
out of the way when it was desirable to get access to the hardware. I'm
not willing to give that up.
A re-write of XenoCopy was the first program that I wrote in C. It shows.
I wish that I were to have the time and energy to go back and rewrite it
properly, using what I have learned since then.
I wish that I were to have been more successful in teaching my students to
program carefully and safely. Bounds checking. But, even such simple
basics as being more careful and remembering that integer division
truncates, that floating points are approximations and an equality
comparison needs to be replaced by checking whether it is "close enough",
etc.
If I were to write XenoCopy again, I would still do it in C. The Sales
Tax Genie TSR would still be in assembly. BUT, the next iterations would
be less buggy.
--
Grumpy Ol' Fred cisin at xenosoft.com
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
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.
5 Dec
5 Dec
5:47 a.m.
Having maintained X.25 networking software written in Fortran-77 when I
worked at Salford University, and written large amounts of Software on
Honeywell L66 and DPS8 kit using "B", give me "C" any day. So a couple
of
answers:-
1. WHY Fortran-77
Well at the time many of the machines we were targeting did not have "C"
compilers that were widely available to all owners of the machines.
I think the major ones were ICL2900, Prime and IBM 370 series. All these had
Fortran-77 installed and usable as we were providing code to UK
Universities.
Apart from the perhaps the Prime none had "C" compilers generally
installed...
2.HOW?
A major problem was there is no dynamic memory in Fortran-77. So we defined
a large array of Character Variables (we called each element a "block") and
then a matrix of integers. Each Character Variable in the array had some
matching integers that could be used to define how the data in the character
variable was to be used, so essentially a "Block Type". As Fortran-77
supports include files we had includes that defined offsets into the
Character Variables and so defined the block structure.......
Of course Fortran or its standard run-time library has no concept of
networking so there was a host of machine dependant code hidden in a
subroutine library.
Definitely a total mis-use of the poor innocent Fortran-77 compiler, which I
must say we broke on a frequent basis....
Dave
G4UGM
-----Original Message-----
From: cctalk [mailto:cctalk-bounces at classiccmp.org] On Behalf Of Guy
Sotomayor
Sent: 04 December 2014 19:13
To: General Discussion: On-Topic and Off-Topic Posts
Subject: Re: C, please die, and take Go with you - Re: Fwd: is there any
word
processing software for the pdp11?
> 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.
when
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 an exception is thrown because of a coding error? You
die--maybe with
some diagnostic information. Very often, there's no way forward.
die.
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 >
> 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.
close
I am in favor of very good compile-time diagnostics, no matter the
language,
however. Getting 150 error messages because you forgot to 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
4 Dec
4 Dec
3:37 p.m.
On Thu, Dec 4, 2014 at 10:52 AM, Fred Cisin <cisin at xenosoft.com> wrote:
Yes, chainsaws are dangerous. So are motorcycles.
Some people ride motorcycles inappropriately, and indeed, some shouldn't
even consider one. Some ride motorcycles for the wrong reasons, such as
inability to afford a car.
I agree with that, and I also believe that adults should be free to
make the decision for themselves. However, in the vast majority of
cases, if people ride a motorcycle and screw up (or someone else
screws up), they are the one that is injured, and relatively little
harm happens to anyone else.
In the case of writing buggy C code, which is nearly the only kind, a
programmer is potentially causing harm to a lot more people,
especially in the future as the IoT takes off. I'm NOT arguing that
the government or even a standards body or NGO should ban C. What I'm
arguing is that we should develop a culture of using more appropriate
tools.
Is C more dangerous than Assembly?
In technical terms,no. In practice as actually applied, maybe, since
many programmers mistakenly believe that C is a high-level language
and assume that they don't need to know or understand what's really
going on. That might work in a bondage-and-discipline language, but in
C it's disastrous. There are numerous existence proofs that C is
dangerous even when used by experts, so anyone using C without fully
understanding it is in for a world of hurt for themself as well as
their victims.
3:25 p.m.
On Thu, Dec 4, 2014 at 10:23 AM, Ian S. King <isking at uw.edu> wrote:
I'm not sure why some people insist on bashing C
because it can be
misused/abused. C is a tool for when you need to touch the metal. It's
just not what anyone should use to write applications.
That's exactly the point. C (and C++) are widely used where they are
inappropriate.
Also C does not have any monopoly on being able to "touch the bare
metal", nor is strong typing necessarily an impediment to doing so.
Ada, despite being a "bondage and discipine" language, actually had as
one of its design requirements the ability to deal with bare metal.
3 Dec
3 Dec
1:32 p.m.
On Wed, 3 Dec 2014, John Ames wrote:
This is why we've got snow blowers with the label "DO NOT USE ON ROOF" on
them. :)
I look at it this way - use the tool most appropriate for the task and
tell the language snobs to See Figure #1.
g.
--
Proud owner of F-15C 80-0007
http://www.f15sim.com - The only one of its kind.
http://www.diy-cockpits.org/coll - Go Collimated or Go Home.
Some people collect things for a hobby. Geeks collect hobbies.
ScarletDME - The red hot Data Management Environment
A Multi-Value database for the masses, not the classes.
http://scarlet.deltasoft.com - Get it _today_!
From: Al
Kossow <aek at bitsavers.org>
People traded safety for speed, and thanks to the net and cowboy
programming, that has turned out to be a bad decision.
Pshaw. C is only as unsafe
as you make it. It's not the language that
has caused, for example, Internet security issues - it's programmers
who refuse to learn well-known lessons like "always, always, *always*
bounds-check network-facing buffers *no matter what*" that give us
things like Heartbleed and any number of other overrun/underrun/etc.
vulnerabilities.
Blaming the language for the badness of bad programmers is like
blaming the chainsaw for the actions of some nitwit who decapitated
himself playing with one.
3669
days inactive
3671
days old
10 comments
9 participants
participants (9)
-
bfranchuk＠jetnet.ab.ca -
cclist＠sydex.com -
cisin＠xenosoft.com -
commodorejohn＠gmail.com -
dave.g4ugm＠gmail.com -
geneb＠deltasoft.com -
ggs＠shiresoft.com -
isking＠uw.edu -
spacewar＠gmail.com