Re: A way to prevent buffer overflow exploits?

Eric O'Dell wrote:
> What I really meant was that it often seems that more bad software
> engineering results from reasoning along the lines of "I don't need
> to check for [condition] because [condition] will never occur" than
> from innocent programmer error, and that past a certain point,
> built-in language safeguards tend to encourage that sort of reasoning.


I'm having difficulties following this. So because people tend to get
less careful if they are routinely handed over chainsaws with
safeguards, you think it's a bad idea to add those safeguards?


More seriously, I think that if an innocent programmer error is always
caught, it becomes truly innocent, and there's no harm if people start
making them on a routine basis. Heck, my programs have lots of type
errors when I run them through the compiler for the first time - i.e.
I'm really relying on safeguards to avoid my arms being cut off. I
don't regard that as bad style though; I can keep my concentration on
other issues, knowing that the compiler will catch any errors in type
declarations anyway.


I'd agree if the compiler didn't catch the error reliably. So the
advice for language designers is: If you add a safeguard, make sure
that programmers know fully well which errors will be caught and which
won't. Error situations where the programmer doesn't know whether
they will be caught or not are just like a rubber safeguard.


Regards,
Joachim
--

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