3 Dec
2014
3 Dec
'14
4:02 p.m.
I suppose not. Perhaps more that using a language that Isn't C and offers
(1) and (2) will ameliorate 99.99% of the problems that follow from using C
incorrectly. Certainly that's true. Can't shoot yourself in the foot if you
don't own a gun. But that's not much to talk about :) I have a habit of
using hyperbole and I guess I really shouldn't because 99.99% of the
population of Earth apparently finds it simply discrediting, rather than a
come-on for a debate!!
I have a lot of hang-ups from my experience in school and in the
new-millennium job market... there are so few opportunities these days; the
people that get the chance to take them; who get to be real programmers and
real engineers; they had better be good. Otherwise you can just play on
nights and weekends like I do. To me, part of being a professional and
doing the job right is not making mistakes. Certainly that's the standard I
hold myself to as a Systems Administrator. People who nail up their shingle
as a professional and subsequently ship buggy garbage don't need a new
language to save them from themselves; they need a new line of work (whoa,
polarizing!)
Best,
Sean
On Wed, Dec 3, 2014 at 6:38 PM, Josh Dersch <derschjo at gmail.com> wrote:
On Wed, Dec 3, 2014 at 3:09 PM, Sean Caron <scaron
at umich.edu> wrote:
code
but
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:
> > 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*
programmer,
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
> huge number that have gone undetected so far.
>
> C advocates always claim that a good programmer will write reliable 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 > 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,
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.