Re: A way to prevent buffer overflow exploits?

khays@sequent.com (Kirk Hays) wrote:
>Type safe languages aren't a cure-all. Bad programmers can make bad
>code in any language, and good programmers are in the minority, and
>great programmers are rare (present company excepted), so I expect to
>see "buffer overflow exploits" (how cute!) type errors for the
>indefinite future.
>
>Programming in C (for example) is like juggling a running chainsaw
>with no chain clutch, handle, off switch, or safety guards. It can be
>done, spectacular results can be achieved, but you know it's going to
>be painful on occasion.


          C does have an off switch. How else are you going to get your
hand cut off while trying to turn it off?


          I'm a great programmer (maybe). I think that the definition of
"great programmer" has to include something about not wanting to make
mistakes and not tempting fate by juggling running chainsaws or doing
other silly things. Call it a sense of responsibility.


          At one point, I was seriously considering using C as my main
language. The power, etc. was tempting, but with the extreme capacity
of the language for allowing you to shoot yourself in the foot, the
arm, the head, the gut, etc. and the various demonstrations of this on
various newsgroups, I said no.


          I like to have correct programs and I like to know about the
errors as soon as I can. I am prepared to give up some flexibility to
get this. Ideally, it's a warning that I can choose to ignore. If
the compiler can catch it, great.


            My programs have enough troubles between vague specs; change
requests; bugs in the program, language system, or operating system;
and so on without me having to worry over ever detail ALL of the time.
Most of the time, I just want to get on with it. When I want to go
under the hood, I want that capability, but I won't trade reliability
all the time for the few times I need under.


          This is not a rant against C. I write end user apps. I rarely
really need C.


>>IMHO, if this is a problem for your organization, it's a sign that
>>your hiring practices, and not your programming tools, are at fault.


          Hiring imperfect people in an inperfect world can be considered a
fault I suppose.


>Oh, my.
>
>So the programmers you hire never have a bad day, an "off by one"
>error, program on a Friday afternoon, fight with their spouses, lack
                                          ^^^^^^^^^^^^^^^^
          You misspelled "Monday morning".


>experience, misuse a macro, get bit by a bug in a compiler, or have to
>maintain someone else's crufty old code?
>
>Beware hubris.
>
>I admire your dedication to the ideals of our shared Art, but remind
>you that the only "science" in "Computer Science" is in the name.
>After 20 years of programming daily for a living, I find that arcanum
>is still the order of the day, and Murphy is our high priest.


            Yeah, what he said, in spades.


Sincerely,


Gene Wirchenko
[I think this just about says it all and brings this thread to an end,
unless someone can drag it back to compilers. -John]
--

Return to the comp.compilers page.
Search the comp.compilers archives again.