3 Dec
2014
3 Dec
'14
3:38 p.m.
On Wed, Dec 3, 2014 at 3:09 PM, Sean Caron <scaron at umich.edu> wrote:
Clearly you're on a religious crusade here.. I
just don't buy the line that
were it not for everyone using this pesky C language, we could live in this
mythical world where exploits don't exist...
That's not the line that was given. No one here is claiming there is a
language that prevents all exploits.
You must be a professional
programmer? Certainly you have strong ideas of what's right and what's
wrong in programming practice... but I feel like you are faulting the
language here while giving what are essentially (sorry, strong language)
hack programmers a pass... Why should it be the responsibility of the
language to save programmers from themselves?
The reality is that we're all "hack programmers." Everyone makes
mistakes. Sometimes these mistakes get caught by others, sometimes they
don't. Some programming languages can help catch more of these mistakes
sooner, or to make some of these mistakes impossible.
In a perfect world, we wouldn't need languages to take responsibility to
"save programmers from themselves," but we don't live in that world and
it's pretty evident that deficiencies in C have resulted in many exploits,
even in the hands of experts.
- Josh
Not necessarily the best
metaphor because I totally appreciate languages like Smalltalk, LISP, et al
but I'm too old to be restricted to safety scissors!
Best,
Sean
On Wed, Dec 3, 2014 at 3:25 PM, Eric Smith <spacewar at gmail.com> wrote:
On Wed, Dec 3, 2014 at 9:21 AM, Sean Caron
<scaron at umich.edu> wrote:
programmer,
But is there necessarily a win in turning a crack
C programmer into a
novice {Smalltalk, LISP, insert your favorite language here...}
programmers?
Of what use is a newborn baby? Of *course* it's of no value if you stop
at turning them into a novice. But if they're actually a *good* they'll become proficient in another
language. I would go so far as to
say
that if they don't become proficient in
another language, given a
reasonable
chance to do so, they aren't actually a good programmer, any C
programming
ability notwithstanding.
still a
Given a short time frame, perhaps it's more
effective to spend
those hours writing code in a language with which you're already
familiar,
rather than spending them picking up a new
language...
And continue writing software that has vulnerabilities. When the tools
don't
provide support for writing reliable software, reliable software mostly
doesn't
get written. For every CERT advisory of a vulnerability, there are huge number that have gone undetected so far.
C advocates always claim that a good programmer will write reliable code
in C, and in a vanishingly small number of cases that's true, but the
reality is that 99.9999% of C code has bugs that either:
1) could have been caught by static analysis in a language with even
slightly better semantics (including strong typing)
2) could have been caught at runtime if the language semantics could
reasonably support bounds checking. In this case the software would
still have a bug, but at worst it would result in denial of service
rather
than privilege escalation and information leakage. (Then there's the
problem of people that use runtime checking during software testing
to protect their valuable test data, but turn runtime checking off
for
production, but that's an argument for
another day.)
There has been a huge amount of research into how to solve those
problems in C, with only partial results. It's a difficult and perhaps
intractable problem because C is a portable assembly language, with
correspondingly low level semantics The "easy" way to solve the problem
is not coming up with bandaids for C, or trying to better train C
programmers; it is to abandon C for a reasonable language.
This doesn't happen at least in part due to managers seeing a huge
glut of C programmers on the market. When all you've got is a hammer...
Note that the same arguments apply to C++. While C++ is no longer
a proper superset of C, it still is close to being one. C++ advocates
will
point
out that a lot of the new stuff in C++ is safer than the old C stuff, but
unfortunately as long as the old C stuff is in there, it gets used and
causes the same old problems. Rather than C++ being a better language
than C, it's a worse language, because it has *all* of the C defects,
plus
additional new ones.