why the usage of gets() is dangerous.

[CBFalconer]

CBFalconer wrote:
.... snip ...


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.

YES. Without the faulty checks, nothing will have been so stamped
in the first place. There is no false assurance lying about. The
programmer is used to having to find bugs.

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

 

[Flash Gordon]

CBFalconer wrote, On 27/11/07 20:47:
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.

 

[jameskuyper]

YES. Without the faulty checks, nothing will have been so stamped
in the first place. There is no false assurance lying about. The
programmer is used to having to find bugs.

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

I still don't get your point. You described someone performing
inadequate testing, and on the basis of that testing attaching a
"VALIDATED" label to the software. That's the fundamental problem; it
has nothing to do with whether or not bounds-checking fat pointers
were used during the inadequate testing. The fact that the fat
pointers didn't reveal the problem was because the testing was
inadequate, and an implementation using ordinary pointers would have
done no better at identifying the problem.

The difference is that there are some tests that could have been
performed where the fat-pointer implementation would have revealed the
defect immediately, while an ordinary implementation might not have.
If those tests weren't performed, it's the fault of the tester, not of
the fat pointer implementation.

 

[CBFalconer]

I still don't get your point. You described someone performing
inadequate testing, and on the basis of that testing attaching a
"VALIDATED" label to the software. That's the fundamental problem;

I think that I have a somewhat different outlook (and experience)
than most, inasmuch as I am not getting much agreement in this
matter. So I am going to abandon the argument. I don't think
there is any real danger of such things appearing in the C world.

No hard feelings.