Re: why the usage of gets() is dangerous.

CBFalconer wrote, On 27/11/07 20:47:
Flash Gordon wrote:
CBFalconer wrote:

... snip ...
Somebody procedes to use it again. All sorts of things blow up. The function is ignored, because it passes the tests in the
original, and it is in a library, and never got recompiled. Don't forget that it has been stamped as VALIDATED in upper case.

I don't want this form of 'checking'.
Without fat pointer and checking you get memory corruption,
occasional crashes etc. Are you honestly saying that is better
than having fat pointer causing it to crash? You still have the
problem that the function has been stamped as validated in either
case. Well, with fat pointers and checking you will probably find
it easier to find the problem because it will crash where the
buffer overrun occurs instead of at some random later point.

You have failed to address the latter part of this paragraph where I address why the later debugging would be easier.

YES. Without the faulty checks, nothing will have been so stamped
in the first place. There is no false assurance lying about.

Programmers who would make that assumption would make it with or without fat pointers and bounds checking. Those who bother to attach a debugger and see where it crashes will immediately know where it crashes and why.

The
programmer is used to having to find bugs.

Most programmers also find tools that pinpoint the bugs more accurately by causing the failure to happen earlier to to be useful.

Note that the VALIDATED version may or may not crash when called.

The same is true of any code that invokes undefined behaviour on any implementation. The programmers who assume that because code has passed a limited number of tests prove code correct make that mistake in any case. By your argument we should not do any testing of any libraries or any SW because then it will be VALIDATED and the programmer will assume something else must be wrong when it crashes (admittedly on the rare occasions I have blamed HW faults I have been proved right, but most crashes are not down to HW faults).

You also singularly fail to address the question of why we have memory barriers at all (most modern desktop OSs protect processes from each other etc) or any other safety feature.
--
Flash Gordon
.

Relevant Pages

  • Re: Troolean operators
    ... Yes, but it crashes all the time, because the programmers, never said, ... true false or something else, they always say, true false or error out, ... bad memory assignment or whatever. ...
    (sci.physics)
  • Re: security issues with forth
    ... Crashes are instructive. ... but these were students writing student exercises. ... a difference between that and professionals writing code that will be ... I see experienced application programmers do this all the time! ...
    (comp.lang.forth)
  • Re: fclose(0)
    ... Some programmers never even see ... the crashes, let alone fix their causes. ... I have a web browser ...
    (comp.lang.c)
  • Re: [opensuse] frustration and suggestions
    ... It is directed at the "features galore, never mind the crashes" attitude of ... more and more "programmers". ... that is just as bad as firefox catching ... itself crashing, imo they should concentrate on eliminating the crashes, ...
    (SuSE)