why the usage of gets() is dangerous.

[jayapal]

Hi all,

Whenever I use the gets() function, the gnu c compiler gives a
warning that it is dangerous to use gets(). why...?

regards,
jayapal.

[CBFalconer]

Malcolm McLean wrote:

"James Kuyper" <ja*********@verizon.netwrote

>By the same logic, to apply my previous analogy, a bullet proof
vest has to work against all bullets, or it's useless. If it
doesn't it gives you no confidence whatsoever that you are safe
from bullets, and the odd pass just encourages ignoring the real
problem, which is that people are shooting at you. That's a
clearly ridiculous argument; and the reason is the logic, not
the analogy.

If a competing vest offers 100% protection then your vest,
offering 99%, will need to be very much cheaper indeed before it
will find a market. However in the absence of anything better,
even 50% protection is much better than nothing.

No, even the cheaper at half price is a pain. It weighs more than
nothing, constricts your movements, and will probably simply be
ignored.

--
Chuck F (cbfalconer at maineline dot net)
<http://cbfalconer.home.att.net>
Try the download section.

--
Posted via a free Usenet account from http://www.teranews.com

[CBFalconer]

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.

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.

--
Chuck F (cbfalconer at maineline dot net)
<http://cbfalconer.home.att.net>
Try the download section.

--
Posted via a free Usenet account from http://www.teranews.com

[Flash Gordon]

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

[jameskuyper]

CBFalconer wrote:

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.

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]

ja*********@verizon.net wrote:

CBFalconer wrote:

>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.

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;

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.

--
Chuck F (cbfalconer at maineline dot net)
<http://cbfalconer.home.att.net>
Try the download section.

--
Posted via a free Usenet account from http://www.teranews.com