gets() - dangerous?

On 23 Dec 2005 20:29:01 -0800, "Lee" <le****@gmail.com> wrote in
comp.lang.c:

Hi

Whenever I use the gets() function, the gnu c compiler gives a
warning that it is dangerous to use gets(). Is this due to the
possibility of array overflow? Is it correct that the program flow can
be altered by giving some specific calculated inputs to gets()? How
could anyone do so once the executable binary have been generated? I
have heard many of the security problems and other bugs are due to
array overflows.

Looking forward to your replies.
Lee

The solution is simple: don't use gets(). Not ever. As to what
happens if you do use gets() and the quantity of input is greater than
the destination space, the C language does not know or care. As to
how this undefined behavior might be exploited by someone with
malicious intent, that too is not a language issue.

The authors of your compiler, quite properly and responsibly, take it
upon themselves to warn you that you should not use gets(). Why are
you still using it?

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html

On 23 Dec 2005 20:29:01 -0800, "Lee" <le****@gmail.com> wrote:

Hi

Whenever I use the gets() function, the gnu c compiler gives a
warning that it is dangerous to use gets(). Is this due to the
possibility of array overflow? Is it correct that the program flow can
Yes
be altered by giving some specific calculated inputs to gets()? How
Yes
could anyone do so once the executable binary have been generated? I
have heard many of the security problems and other bugs are due to
array overflows.

Looking forward to your replies.

Don't hold your breath. Buffer overflow is not a c language topic.
<<Remove the del for email>>

Barry Schwarz wrote:

Don't hold your breath. Buffer overflow is not a c language topic.

But is well documented elsewhere:
http://en.wikipedia.org/wiki/Buffer_overflow

On 23 Dec 2005 21:53:53 -0800, "nickptar" <ni******@gmail.com> wrote
in comp.lang.c:

Barry Schwarz wrote:

Don't hold your breath. Buffer overflow is not a c language topic.

But is well documented elsewhere:
http://en.wikipedia.org/wiki/Buffer_overflow

Nothing in Wikipedia can be considered well documented without
additional credible references.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html

nickptar wrote:

Barry Schwarz wrote:

Don't hold your breath. Buffer overflow is not a c language topic.

But is well documented elsewhere:
http://en.wikipedia.org/wiki/Buffer_overflow

This is possibly the most poorly-written and inaccurate article I have
read on wikipedia, did you even read it before posting the link?

Robert Gamble

Jack Klein wrote:

"Lee" <le****@gmail.com> wrote in comp.lang.c:

Whenever I use the gets() function, the gnu c compiler gives
a warning that it is dangerous to use gets(). Is this due to
the possibility of array overflow? Is it correct that the
program flow can be altered by giving some specific calculated
inputs to gets()? How could anyone do so once the executable
binary have been generated? I have heard many of the security
problems and other bugs are due to array overflows.

The solution is simple: don't use gets(). Not ever. As to
what happens if you do use gets() and the quantity of input is
greater than the destination space, the C language does not know
or care. As to how this undefined behavior might be exploited
by someone with malicious intent, that too is not a language
issue.

The authors of your compiler, quite properly and responsibly,
take it upon themselves to warn you that you should not use
gets(). Why are you still using it?

However you can always use ggets() (note the extra g, for good).
This was written to have the convenience and simplicity of gets,
without any possible overrun. The ISO standard source (thus
portable to any system) is available at:

<http://cbfalconer.home.att.net/download/ggets.zip>

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell.org/google/>

"Jack Klein" <ja*******@spamcop.net> wrote

Nothing in Wikipedia can be considered well documented without
additional credible references.

<OT>
That's what crusty academics say because a new competitor has come along. Of
course they want people to rely on peer-reviewed literature where they are
the peers.

In fact something like 50% of scientific papers make conclusions which are
later refuted or challenged by further papers. (read Iohannis for a
peer-reviewed take on the subject).
No medium written by humans can guarantee complete accuracy, freedom form
bias, etc. Wikipedia is no different from any other source.

Lee said:

Hi

Whenever I use the gets() function, the gnu c compiler gives a
warning that it is dangerous to use gets().
No, it's the linker that warns you, not the compiler.
Is this due to the possibility of array overflow?
Yes.
Is it correct that the program flow can be altered by giving some
specific calculated inputs to gets()?
Yes.
How could anyone do so once the executable binary have been generated?
By overwriting the stack, for example. On a typical machine, the program is
loaded from disk into memory before execution. During execution, it is
present in memory. And the thing about memory is that it can be overwritten
with new values.
I have heard many of the security problems and other bugs are due to
array overflows.

Quite.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

Malcolm wrote:

"Jack Klein" <ja*******@spamcop.net> wrote

Nothing in Wikipedia can be considered well documented without
additional credible references.

<OT>
That's what crusty academics say because a new competitor has come along. Of
course they want people to rely on peer-reviewed literature where they are
the peers.

However, it is always useful to see where the author got the
idea/solution or based her/his own conclusions.
In fact something like 50% of scientific papers make conclusions which are
later refuted or challenged by further papers. (read Iohannis for a
peer-reviewed take on the subject).
No medium written by humans can guarantee complete accuracy, freedom form
bias, etc. Wikipedia is no different from any other source.

Yes, for that reason papers are wrote and commented and referenced. To
prove their accuracy, correct them or throw them away.

"Giannis Papadopoulos" <ip******@inf.uth.gr> wrote

No medium written by humans can guarantee complete accuracy, freedom form
bias, etc. Wikipedia is no different from any other source.

Yes, for that reason papers are wrote and commented and referenced. To
prove their accuracy, correct them or throw them away.

Papers are peer-reviewed as a means of selecting which are and which are not
published. Most publications receive more material then they can or want to
print.

Further claims are then made for peer-reviewed literature, which are largely
unwarranted. In particular, peer review does not "prove accuracy".

Jack Klein wrote:

On 23 Dec 2005 20:29:01 -0800, "Lee" <le****@gmail.com> wrote in
comp.lang.c:

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

Personally, I am waiting for the compiler that implements gets as the
following:

char * gets (char * s) {
unlink (__FILE__); /* POSIX */
return s;
}

Since it would improve its predictability.
[...] Is this due to the

possibility of array overflow? Is it correct that the program flow can
be altered by giving some specific calculated inputs to gets()? How
could anyone do so once the executable binary have been generated? I
have heard many of the security problems and other bugs are due to
array overflows.

Looking forward to your replies.
Lee

(My recommendation is to *learn* about the problem here:
http://www.pobox.com/~qed/userInput.html )
The solution is simple: don't use gets(). Not ever.
Hmmm ... here's a rhetorical question. What is the value of a
specifying a function in the language definition if you can't even use
it -- not ever?
[...] As to what
happens if you do use gets() and the quantity of input is greater than
the destination space, the C language does not know or care. As to
how this undefined behavior might be exploited by someone with
malicious intent, that too is not a language issue.

The authors of your compiler, quite properly and responsibly, take it
upon themselves to warn you that you should not use gets(). Why are
you still using it?

Well, fundamentally, the reason he uses it is because its there, and
because the language standard itself continues to endorse the use of
this function. Unfortunately, the compiler, even after warning you,
and with all sorts of comments telling you about it in the man pages,
goes ahead and compiles/links the code. The compiler/linker *could*
simply dump out with an error unless you give it a -unsafe flag or
something like that. I still don't know who exactly is pulling for the
continued support for this function, but they seem to have a lot of
influence over compiler vendors and the standards committee.

The OP sees this linker warning as an annoyance, and wants to make the
annoyance go away. He's lucky in that here are some reponses here
telling him to stop using the function, but on another day he'd just
get a lot of bickering about top-posting, or forgetting to quote a
previous post or quoting too much of one.

--
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sf.net/

On 2005-12-24, we******@gmail.com <we******@gmail.com> wrote:

Jack Klein wrote:

On 23 Dec 2005 20:29:01 -0800, "Lee" <le****@gmail.com> wrote in
comp.lang.c:

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

Personally, I am waiting for the compiler that implements gets as the
following:

char * gets (char * s) {
unlink (__FILE__); /* POSIX */
return s;
}

Since it would improve its predictability.

The problem is that, while gets _can_ invoke undefined behavior based
on things the programmer has no control over, it is well-defined as long
as that does not happen - this is the same reason that it's not legal
for an implementation to reject a program using it

Jack Klein wrote:

On 23 Dec 2005 21:53:53 -0800, "nickptar" <ni******@gmail.com> wrote
in comp.lang.c:

Barry Schwarz wrote:

Don't hold your breath. Buffer overflow is not a c language topic.

But is well documented elsewhere:
http://en.wikipedia.org/wiki/Buffer_overflow

Nothing in Wikipedia can be considered well documented without
additional credible references.

Uh ... according to a recent independent study, the Encyclopedia
Britanica has only a 33% better error rate than Wikipedia (meaning
Wikipedia has roughly 33% more errors per article than Britanica.) Now
of course, that doesn't mean you should rely solely on Wikipedia, but
what it means is that if you should apply roughly the same degree of
trust to Wikipedia that you would a reasonable encyclopedia (maybe its
as good as Funk & Wagnals :) )

The funny ironic thing about supposed experts who complain about the
accuracy of Wikipedia is that they don't bother to come to the
realization that the degree of correctness of any given Wikipedia
article is actually in their hands. I wonder -- in who's interest is
it to denigrate or attack Wikipedia.

--
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sf.net/

we******@gmail.com said:

Jack Klein wrote:

On 23 Dec 2005 20:29:01 -0800, "Lee" <le****@gmail.com> wrote in
comp.lang.c:

> Whenever I use the gets() function, the gnu c compiler gives a
> warning that it is dangerous to use gets().
Personally, I am waiting for the compiler that implements gets as the
following:

char * gets (char * s) {
unlink (__FILE__); /* POSIX */

remove(__FILE__); /* ISO */
The solution is simple: don't use gets(). Not ever.

Hmmm ... here's a rhetorical question. What is the value of a
specifying a function in the language definition if you can't even use
it -- not ever?

None whatsoever. So let's drop it from the language definition.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

On 24 Dec 2005 09:35:29 -0800, in comp.lang.c , we******@gmail.com
wrote:

Uh ... according to a recent independent study, the Encyclopedia
Britanica has only a 33% better error rate than Wikipedia
If you examine the study rather than news reports on it from seemingly
uninformed journos, you will find that Nature deliberately excluded
articles which might be subject to any contention, disagreement or
debate, ie anything in humanities, much of the science, politics, and
all biography. This eliminates virtually all of Wikipedia I suspect.

And 33% more errors in the articles there is no debate about sounds
pretty dang poor to me. :-)
The funny ironic thing about supposed experts who complain about the
accuracy of Wikipedia is that they don't bother to come to the
realization that the degree of correctness of any given Wikipedia
article is actually in their hands.
I always love this bullshit argument.
"Someone else wrote lies and/or misinformation but thats not their
fault, its yours for not spending your time fixing it."

Er, no. Its the fault of the person who was too lazy, biassed or
ignorant to get the facts right in the first place, and its the fault
of the maintainers of wikipedia for not applying better editorial
control.
I wonder -- in who's interest is it to denigrate or attack Wikipedia.

And in whose interest is it to defend it, even when faced with a
glaring failure ?

----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----

we******@gmail.com a écrit :

Personally, I am waiting for the compiler that implements gets as the
following:

char * gets (char * s) {
unlink (__FILE__); /* POSIX */
Why using an extension when the standard function does exist ?

remove (__FILE__);
return s;
}

BTW, I suppose that you want some [C99] 'inline'. If not, the effect
would be limited (the implementation file is probably not that close)

--
A+

Emmanuel Delahaye

Emmanuel Delahaye said:

we******@gmail.com a écrit :

char * gets (char * s) {
unlink (__FILE__); /* POSIX */
Why using an extension when the standard function does exist ?

Good question.
remove (__FILE__);

return s;
}

BTW, I suppose that you want some [C99] 'inline'. If not, the effect
would be limited (the implementation file is probably not that close)

Well, in all fairness to websnarf, those foolish enough to use gets() would,
one hopes, tend to be ill-informed students who will be running their
student exercise programs on the very machine on which they are compiling
those programs.

As an educational LART, it's not a terribly bad idea.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

Richard Heathfield wrote:

Emmanuel Delahaye said:

we******@gmail.com a écrit :

char * gets (char * s) {
unlink (__FILE__); /* POSIX */
Why using an extension when the standard function does exist ?

I was just unaware of the existence of remove(), but happened to run
across unlink() in some incidental search through my documentation some
time ago. Learn a new thing every day.
Good question.

remove (__FILE__);

return s;
}
BTW, I suppose that you want some [C99] 'inline'. If not, the effect
would be limited (the implementation file is probably not that close)

Right, and if we don't have C99 then we can't force this to work. Oh
what a great standard this language has ... *sigh*. Anyhow, my comment
was really aimed at compiler implementors not general programmers.
Well, in all fairness to websnarf, those foolish enough to use gets() would,
one hopes, tend to be ill-informed students who will be running their
student exercise programs on the very machine on which they are compiling
those programs.

As an educational LART, it's not a terribly bad idea.

*DING DING DING DING DING!* Give the man a prize.

--
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sf.net/

Richard Heathfield wrote
(in article
<do**********@nwrdmz01.dmz.ncs.ea.ibs-infra.bt.com>):

Emmanuel Delahaye said:

BTW, I suppose that you want some [C99] 'inline'. If not, the effect
would be limited (the implementation file is probably not that close)

... those foolish enough to use gets() would,
one hopes, tend to be ill-informed students who will be running their
student exercise programs on the very machine on which they are compiling
those programs.

Possibly, but I wonder how many hits you would find if you could
grep the source on all of sourceforge for gets(). I suspect
it's nonzero, and that represents a tiny portion of the software
out there that could contain it, outside of "student code".
(Yes, I know a lot of what is on sourceforge is student level,
at best)
--
Randy Howard (2reply remove FOOBAR)
"The power of accurate observation is called cynicism by those
who have not got it." - George Bernard Shaw

Barry Schwarz <sc******@oz.net> writes:
[...]

Don't hold your breath. Buffer overflow is not a c language topic.

Sure it is, but the discussion ends with the phrase "undefined
behavior".

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

Richard Heathfield wrote:

Lee said:

Hi

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

No, it's the linker that warns you, not the compiler.

Is this due to the possibility of array overflow?

Yes.

Is it correct that the program flow can be altered by giving some
specific calculated inputs to gets()?

Yes.

How could anyone do so once the executable binary have been generated?

By overwriting the stack, for example. On a typical machine, the program is
loaded from disk into memory before execution. During execution, it is
present in memory. And the thing about memory is that it can be overwritten
with new values.

I have heard many of the security problems and other bugs are due to
array overflows.

Quite.

When was it that use of gets() became widely known as evil? I started C
fifteen or more years ago and it was evil then. Why are some now just
discovering it is evil? Is anyone listening?

--
Joe Wright
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---

Randy Howard said:

Possibly, but I wonder how many hits you would find if you could
grep the source on all of sourceforge for gets(). I suspect
it's nonzero, and that represents a tiny portion of the software
out there that could contain it, outside of "student code".
(Yes, I know a lot of what is on sourceforge is student level,
at best)

If a program contains a call to gets(), it is broken. The fact that some
programs contain calls to gets() is not a good argument for continuing to
offer support for gets() in its present form.

If gets() is removed from the library or re-cast as something like
system("format c: /y") or system("rm -rf *") or whatever, then this will
not affect any well-written programs whatsoever. As for those programs it
does affect, we're better off without them.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

Mark McIntyre wrote:

On 24 Dec 2005 09:35:29 -0800, in comp.lang.c , we******@gmail.com
wrote:

Uh ... according to a recent independent study, the Encyclopedia
Britanica has only a 33% better error rate than Wikipedia
If you examine the study rather than news reports on it from seemingly
uninformed journos, you will find that Nature deliberately excluded
articles which might be subject to any contention, disagreement or
debate, ie anything in humanities, much of the science, politics, and
all biography. This eliminates virtually all of Wikipedia I suspect.

But it would eliminate all of Britanica too by the same reasoning.
Obviously they wanted to pick topics for which they could find real
authorities that could establish absolute truth on the topic. That's a
little hard to do with abortion.
And 33% more errors in the articles there is no debate about sounds
pretty dang poor to me. :-)
Well as long as we are going to cite the actual data -- they found an
average of 3 errors per article in Britanica, and 4 in Wikipedia.
Personally I find anything above about 0.001 pretty unacceptable to me,
but if this is the best standard we have, then I just see it as a wash
-- Britanica and Wikipedia are roughly the same, and you need to go
beyond them for any serious research anyways.

As a side note, I've made about a half dozen significant contributions
to Wikipedia myself, and try very hard to steer away from anything that
isn't clearly true or which incorporates my personal bias. So when I
read that story, I was a little saddened to learn that the error rate
is so high (I really don't think my error rate on WikiPedia is anywhere
near that), but equally shocked that Britanica is not better in any way
that seriously matters.

What's poor is that there is an error rate in articles that is greater
than 1 per, let alone as bad as 3 or 4. Is the human race really that
pathetic that technical integrity is beyond our grasp? Britanica is
not relevantly better -- so the problem is not with Wikipedia but with
people's accuracy in general.

The funny ironic thing about supposed experts who complain about the
accuracy of Wikipedia is that they don't bother to come to the
realization that the degree of correctness of any given Wikipedia
article is actually in their hands.

I always love this bullshit argument.
"Someone else wrote lies and/or misinformation but thats not their
fault, its yours for not spending your time fixing it."

No the problem is that these people spend their time yelling about the
inaccuracies at the top of their lungs instead of being part of the
solution, for which there is an obvious need.
Er, no. Its the fault of the person who was too lazy, biassed or
ignorant to get the facts right in the first place, and its the fault
of the maintainers of wikipedia for not applying better editorial
control.

This shows ignorance of how Wikipedia works. There *IS* no structured
editorial control outside the contributors themselves. And there is no
*fault* here. If you don't have the patience to be part of the
solution, your standing in decrying its problems are seriously
undermined and IMHO, have no value. You didn't pay for Wikipedia, and
you didn't put in any effort to make it better, and yet you are going
to complain about it rather than either marvelling at just how good it
is considering or helping make it better.

This just seems to me like seeing an deaf old lady trying to cross a
railroad track with a train coming, then pulling up a lawn chair and
saying "Wow, this accident is going to be good!"

I wonder -- in who's interest is it to denigrate or attack Wikipedia.

And in whose interest is it to defend it, even when faced with a
glaring failure ?

Having a universally accessible, amazing large, somewhat accountable,
up to date, and free encyclopedia with an accuracy rate (which I have a
small role in assisting) similar to commercial offerings? See, unlike
some people, I actually see a lot of *value* in Wikipedia -- and I
think a lot of people do. If the effort I put into it is mirrored by
others, then it will mean that I should expect that level of content
and accuracy of the thing to be extremely high.

As an aside, I recently looked up information about Sucralose and
Aspartame -- I was just looking up basic information, and as
comparison, I was also googled for information on those two things.
The whole business about stability, how they are mixed with other sugar
substitutes, and the process by which they are made, and the safety
arguments for each comes across is a very clear and structured way in
the Wikipedia articles. I *learned* something from Wikipedia that I
just couldn't get from google searches, and that aren't going to be in
obsolete versions of Britanica, or sparse resources like Microsoft's
Encarta (the last two, which nobody seems to criticize with anywhere
near the volume we're seeing Wikipedia criticism.) Now if I want
*real* information about those sugar substitutes, I am going to have to
collect data myself from various FDA and equivalents from other
countries (since I don't really trust the american one.) That's a bit
of a research project considering I just wanted basic information.

So you can count me among the defenders.

--
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sf.net/

Joe Wright said:

When was it that use of gets() became widely known as evil?
1988, I think.
Is anyone listening?

Alas, no.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

Richard Heathfield wrote
(in article
<do**********@nwrdmz03.dmz.ncs.ea.ibs-infra.bt.com>):

Randy Howard said:

Possibly, but I wonder how many hits you would find if you could
grep the source on all of sourceforge for gets(). I suspect
it's nonzero, and that represents a tiny portion of the software
out there that could contain it, outside of "student code".
(Yes, I know a lot of what is on sourceforge is student level,
at best)
If a program contains a call to gets(), it is broken. The fact that some
programs contain calls to gets() is not a good argument for continuing to
offer support for gets() in its present form.

Which is why I wasn't arguing for continued support. I was
simply commenting about the idea that it was useful for teaching
purposes, which I'm not sold on.
If gets() is removed from the library or re-cast as something like
system("format c: /y") or system("rm -rf *") or whatever, then this will
not affect any well-written programs whatsoever.
Gee, that's likely.
As for those programs it does affect, we're better off without them.

Agreed.

--
Randy Howard (2reply remove FOOBAR)
"The power of accurate observation is called cynicism by those
who have not got it." - George Bernard Shaw

Joe Wright wrote
(in article <p4******************************@comcast.com>):

When was it that use of gets() became widely known as evil? I started C
fifteen or more years ago and it was evil then.
Sounds about right.
Why are some now just discovering it is evil? Is anyone listening?

For the same reason that "news" is considered recurring daily if
not hourly discussion of some missing girl in the caribbean six
months after it happened.

Tech "news" is limited to the latest cool video card for gaming.
What we need is a "slashdot" for actual programmers, rather
than a version aimed at those that wish to pretend to be
technical by discussing the latest gadget trends.

Usenet used to serve that purpose, but a very small percentage
of the tech community is involved in it today.

--
Randy Howard (2reply remove FOOBAR)
"The power of accurate observation is called cynicism by those
who have not got it." - George Bernard Shaw

On 2005-12-24, Richard Heathfield <in*****@invalid.invalid> wrote:

Joe Wright said:

When was it that use of gets() became widely known as evil?

1988, I think.

Why did it make it into the standard, then? Other things from the base
document [IIRC for the library it was the "/usr/group" proto-posix
standard] didn't make it in, or were changed

Is anyone listening?

Alas, no.

On 2005-12-24, Randy Howard <ra*********@FOOverizonBAR.net> wrote:

Richard Heathfield wrote
(in article
<do**********@nwrdmz03.dmz.ncs.ea.ibs-infra.bt.com>):

Randy Howard said:

Possibly, but I wonder how many hits you would find if you could
grep the source on all of sourceforge for gets(). I suspect
it's nonzero, and that represents a tiny portion of the software
out there that could contain it, outside of "student code".
(Yes, I know a lot of what is on sourceforge is student level,
at best)

If a program contains a call to gets(), it is broken. The fact that some
programs contain calls to gets() is not a good argument for continuing to
offer support for gets() in its present form.

Which is why I wasn't arguing for continued support. I was
simply commenting about the idea that it was useful for teaching
purposes, which I'm not sold on.

If gets() is removed from the library or re-cast as something like
system("format c: /y") or system("rm -rf *") or whatever, then this will
not affect any well-written programs whatsoever.

Gee, that's likely.

A more likely change is to add a required diagnostic [some
implementations already provide such a diagnostic] and perhaps to allow
such programs to fail to translate.

As for those programs it does affect, we're better off without them.

Agreed.

Randy Howard said:

I was
simply commenting about the idea that it was useful for teaching
purposes, which I'm not sold on.

Nobody has suggested that gets() is useful for teaching purposes, as far as
I'm aware. What somebody did suggest was that an overtly destructive
implementation of gets() would have educational value. I think it's called
aversion therapy.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

On Sat, 24 Dec 2005 21:27:06 +0000 (UTC), in comp.lang.c , Jordan Abel
<jm****@purdue.edu> wrote:

On 2005-12-24, Richard Heathfield <in*****@invalid.invalid> wrote:

Joe Wright said:

When was it that use of gets() became widely known as evil?

1988, I think.

Why did it make it into the standard, then? Other things from the base
document [IIRC for the library it was the "/usr/group" proto-posix
standard] didn't make it in, or were changed

Most likely, lots of existing code using it already.

----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----

On 24 Dec 2005 12:30:16 -0800, in comp.lang.c , we******@gmail.com
wrote:

But it would eliminate all of Britanica too by the same reasoning.
Incorrect: It would eliminate 50% less of Britannica.
Obviously they wanted to pick topics for which they could find real
authorities that could establish absolute truth on the topic. That's a
little hard to do with abortion.
Perhaps you should actually read the Nature article, instead of
guessing.
-- Britanica and Wikipedia are roughly the same, and you need to go
beyond them for any serious research anyways.
33% is significantly outside the statistical level of 'sameness' for
the article population they examined. Do you have any idea about
stats?

I always love this bullshit argument.
"Someone else wrote lies and/or misinformation but thats not their
fault, its yours for not spending your time fixing it."

No the problem is that these people spend their time yelling

No, this isn't the problem. Trying to blame the people who spot the
errors is classic defensive behaviour of someone who knows they're
wrong by the way,
about the
inaccuracies at the top of their lungs instead of being part of the
solution, for which there is an obvious need.
I recommend you read the Register's excellent series of articles on
exactly what happens when one actually /does/ try to correct glaring
errors, omissions and falsehoods.

Er, no. Its the fault of the person who was too lazy, biassed or
ignorant to get the facts right in the first place, and its the fault
of the maintainers of wikipedia for not applying better editorial
control.

This shows ignorance of how Wikipedia works. There *IS* no structured
editorial control outside the contributors themselves.

This is precisely my point. There is no editorial control, so there
is nothing, nothing at all, to prevent complete lies, falsehoods,
misunderstandings and other mistakes.
If you don't have the patience to be part of the
solution,
Ah. I didn't realise I was talking to a cretinous utopian "the web is
god" lunatic.
So you can count me among the defenders.

I pity you.

----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----

> Whenever I use the gets() function, the gnu c compiler gives a

warning that it is dangerous to use gets(). Is this due to the
possibility of array overflow?
Yes, plus the inability to do ANYTHING to prevent it until
it's too late.
Is it correct that the program flow can
be altered by giving some specific calculated inputs to gets()?
Chances are, you can alter the program flow by simply giving gets()
a sufficiently long line without calculating much of anything. This
is particularly true if the input buffer for gets() is an auto
character array. (Although this is system-specific, it is likely
to amount to "scribbling on the return address in the stack frame",
causing a branch to, err, somewhere) The program will likely just
crash rather than send out tons of Viagra ads for you, but often
that's enough to do damage.
How
could anyone do so once the executable binary have been generated? I
Why don't you ask the FBI Computer Task Force?

have heard many of the security problems and other bugs are due to
array overflows.

Gordon L. Burditt

On Sat, 24 Dec 2005 09:28:12 +0000 (UTC), "Malcolm"
<re*******@btinternet.com> wrote in comp.lang.c:

"Jack Klein" <ja*******@spamcop.net> wrote

Nothing in Wikipedia can be considered well documented without
additional credible references.
<OT>
That's what crusty academics say because a new competitor has come along. Of
course they want people to rely on peer-reviewed literature where they are
the peers.

And your sentence, above, is what many uncredentialed individuals say
when they want their (opinions, theories, etc.) given full weight
without the necessity of making the effort to obtain the credentials.
Note that I am not saying this is so in your case, nor am I attempting
to insult you.

Quite a few problems have been documented with Wikipedia, several just
recently. One of the real problems with Wikipedia, mostly absent from
formal peer-review literature, is the anonymity and lack of
accountability of the contributors.
In fact something like 50% of scientific papers make conclusions which are
later refuted or challenged by further papers. (read Iohannis for a
peer-reviewed take on the subject).
No medium written by humans can guarantee complete accuracy, freedom form
bias, etc. Wikipedia is no different from any other source.

Wikipedia is very much different from many other sources. I made no
claims whatsoever about its quality, accuracy, or freedom from bias. I
merely responded to a line in an earlier post, which you snipped,
where a poster claimed that something was "well documented" followed
by a link to Wikipedia.

Based on recent well publicized events, I maintain that existence of a
Wikipedia article, by itself, does not guarantee that the atricle's
subject is well documented.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html

Richard Heathfield wrote
(in article
<do**********@nwrdmz03.dmz.ncs.ea.ibs-infra.bt.com>):

Randy Howard said:

I was
simply commenting about the idea that it was useful for teaching
purposes, which I'm not sold on.

Nobody has suggested that gets() is useful for teaching purposes, as far as
I'm aware. What somebody did suggest was that an overtly destructive
implementation of gets() would have educational value. I think it's called
aversion therapy.

Ahh. I misunderstood then.

--
Randy Howard (2reply remove FOOBAR)
"The power of accurate observation is called cynicism by those
who have not got it." - George Bernard Shaw

"Jack Klein" <ja*******@spamcop.net> wrote

That's what crusty academics say because a new competitor has come along.
Of
course they want people to rely on peer-reviewed literature where they
are
the peers.
And your sentence, above, is what many uncredentialed individuals say
when they want their (opinions, theories, etc.) given full weight
without the necessity of making the effort to obtain the credentials.
Note that I am not saying this is so in your case, nor am I attempting
to insult you.

There's a fuss at our university about students referencing Wikipedia. The
fact is that the student obtains his knowledge from Wikipedia, because if
you want go from knowing nothing about a topic to having some level of
background, the easiest and legitimate way is to type "Jacobi decomposition"
into Wikipedia.
Quite a few problems have been documented with Wikipedia, several just
recently. One of the real problems with Wikipedia, mostly absent from
formal peer-review literature, is the anonymity and lack of
accountability of the contributors.
There is a case for ending the tradition of anonymity.
Wikipedia is very much different from many other sources. I made no
claims whatsoever about its quality, accuracy, or freedom from bias. I
merely responded to a line in an earlier post, which you snipped,
where a poster claimed that something was "well documented" followed
by a link to Wikipedia.

Based on recent well publicized events, I maintain that existence of a
Wikipedia article, by itself, does not guarantee that the atricle's
subject is well documented.

It's a new medium. It has its problems. So too do all other sources of
information. It must not be dismissed, but I agree that one mustn't accept
everything written as authoritative.

Malcolm wrote:

"Jack Klein" <ja*******@spamcop.net> wrote

That's what crusty academics say because a new competitor has come along.
Of
course they want people to rely on peer-reviewed literature where they
are
the peers.

And your sentence, above, is what many uncredentialed individuals say
when they want their (opinions, theories, etc.) given full weight
without the necessity of making the effort to obtain the credentials.
Note that I am not saying this is so in your case, nor am I attempting
to insult you.

There's a fuss at our university about students referencing Wikipedia. The
fact is that the student obtains his knowledge from Wikipedia, because if
you want go from knowing nothing about a topic to having some level of
background, the easiest and legitimate way is to type "Jacobi decomposition"
into Wikipedia.

Yes, I have found it very useful to make a jump start on a new subject.
And I may reference it, but I cannot see how can any paper or anything
else rely entirely on wikipedia.

Maybe in some years, when Google or someone else will collect all human
written knowledge and research and post it on the Internet, wikipedia
may act as a central "knowledge hub"...

Malcolm wrote:

"Jack Klein" <ja*******@spamcop.net> wrote

That's what crusty academics say because a new competitor has come along.
Of course they want people to rely on peer-reviewed literature where they
are the peers.

And your sentence, above, is what many uncredentialed individuals say
when they want their (opinions, theories, etc.) given full weight
without the necessity of making the effort to obtain the credentials.
Note that I am not saying this is so in your case, nor am I attempting
to insult you.

There's a fuss at our university about students referencing Wikipedia. The
fact is that the student obtains his knowledge from Wikipedia, because if
you want go from knowing nothing about a topic to having some level of
background, the easiest and legitimate way is to type "Jacobi decomposition"
into Wikipedia.

But its not just that. You can also get up to date information that is
directly integrated into articles even of a historical nature (for
example if a FOIA request reveals some activity by the CIA from 50
years ago, and this has a previously unrealized perspective on history,
or whatever.) You can also get information from corporate insiders, or
from people who otherwise can distill really convoluted information
into simple short articles that would otherwise not find a normal
mainstream vehicle for being revealed. (Like details about Sucralose
and Aspartame.)

Quite a few problems have been documented with Wikipedia, several just
recently. One of the real problems with Wikipedia, mostly absent from
formal peer-review literature, is the anonymity and lack of
accountability of the contributors.

There is a case for ending the tradition of anonymity.

Yeah, and of course the people who are crying a river about it, don't
bother to notice that things *ARE* being done about this. (Only
registered users can author new articles, certain articles are blocked
from being editted except by credible wikipedians, etc.)

Wikipedia is very much different from many other sources. I made no
claims whatsoever about its quality, accuracy, or freedom from bias. I
merely responded to a line in an earlier post, which you snipped,
where a poster claimed that something was "well documented" followed
by a link to Wikipedia.

Based on recent well publicized events, I maintain that existence of a
Wikipedia article, by itself, does not guarantee that the atricle's
subject is well documented.

It's a new medium. It has its problems. So too do all other sources of
information. It must not be dismissed, but I agree that one mustn't accept
everything written as authoritative.

And that's the line of reasoning that just doesn't have play with the
naysayers. And I don't know why. This is the *OBVIOUS* most well
reasoned position to take -- its new, and its got growing pains, and is
otherwise quite remarkable given this situation. "A new technology is
not perfect" -- wow what impressive and deep criticism.

The vicious attacks on Wikipedia in the recent press about it are one
sided and completely out of proportion. Its as if there is some other
adgenda at work here but I don't quite understand it. Who would have
some innate hatred of the concept a large free and pervasive
encyclopedia whose quality is remarkable given the premise of being
built by random contributors? Is this campaign being waged by
Britanica? By historians or other intellectuals who don't like being
second guessed with a Wikipedia search? The news media who don't like
public dissemination of inconvenient truths and perspective to get in
the way of their editorial spin? I dunno -- those all seems a bit on
the conspiratorial side, but there's no denying the existence of a
concerted campaign against Wikipedia.

--
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sf.net/

Mark McIntyre said:

On 24 Dec 2005 12:30:16 -0800, in comp.lang.c , we******@gmail.com
wrote:

This shows ignorance of how Wikipedia works. There *IS* no structured
editorial control outside the contributors themselves.

This is precisely my point. There is no editorial control, so there
is nothing, nothing at all, to prevent complete lies, falsehoods,
misunderstandings and other mistakes.

Or even simple partisanship. Wikipedia shows considerable dislike for C, but
is very positive about, say, C++, Python, and Lisp.

Encyclopaediae are supposed to be impartial. Whoever wrote the C bit did not
honour this tradition. Not sure why - for heaven's sake, it's only a
programming language! But take a look, and you'll see a "criticisms"
section - which is not something I noticed in the C++, Python or Lisp
sections. Does this mean those languages are beyond criticism? Or does it
simply mean the Wikids don't understand C very well?

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

we******@gmail.com said:

The vicious attacks on Wikipedia in the recent press about it are one
sided and completely out of proportion.
Who cares? What would the press know about it?
Its as if there is some other
adgenda at work here but I don't quite understand it.

I like C. I read the Wikipedia article on C. It's very anti-C, and clearly
written by someone who doesn't know C well enough to use it properly.

The Wikipedia attitude to C is like that of an amateur cook railing against
the dangers of carving knives, and recommending butter knives for all your
carving needs.

I also read some of the Wiki articles on other languages - C++, Python,
Lisp. No such anti-language sentiment there.

From a comp.lang.c perspective, then, Wikipedia sucks.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

On 2005-12-26, Richard Heathfield <in*****@invalid.invalid> wrote:

we******@gmail.com said:

The vicious attacks on Wikipedia in the recent press about it are one
sided and completely out of proportion.

Who cares? What would the press know about it?

Its as if there is some other
adgenda at work here but I don't quite understand it.

I like C. I read the Wikipedia article on C. It's very anti-C, and clearly
written by someone who doesn't know C well enough to use it properly.

The Wikipedia attitude to C is like that of an amateur cook railing against
the dangers of carving knives, and recommending butter knives for all your
carving needs.

I also read some of the Wiki articles on other languages - C++, Python,
Lisp. No such anti-language sentiment there.

From a comp.lang.c perspective, then, Wikipedia sucks.

So edit it to make it a more neutral point of view.

Richard Heathfield wrote:

Mark McIntyre said:

On 24 Dec 2005 12:30:16 -0800, in comp.lang.c , we******@gmail.com
wrote:

This shows ignorance of how Wikipedia works. There *IS* no structured
editorial control outside the contributors themselves.

This is precisely my point. There is no editorial control, so there
is nothing, nothing at all, to prevent complete lies, falsehoods,
misunderstandings and other mistakes.

Or even simple partisanship. Wikipedia shows considerable dislike for C, but
is very positive about, say, C++, Python, and Lisp.

Encyclopaediae are supposed to be impartial. Whoever wrote the C bit did not
honour this tradition. Not sure why - for heaven's sake, it's only a
programming language! But take a look, and you'll see a "criticisms"
section - which is not something I noticed in the C++, Python or Lisp
sections. Does this mean those languages are beyond criticism? Or does it
simply mean the Wikids don't understand C very well?

Clearly an opportunity for you Richard, to set the record straight. You
have credentials enough to be accepted by Wiki I'm sure. And you'd be
good at it, it's only writing after all. Not reading. :-)

--
Joe Wright
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---

Joe Wright said:

Richard Heathfield wrote:

Encyclopaediae are supposed to be impartial. Whoever wrote the C bit did
not honour this tradition. Not sure why - for heaven's sake, it's only a
programming language! But take a look, and you'll see a "criticisms"
section - which is not something I noticed in the C++, Python or Lisp
sections. Does this mean those languages are beyond criticism? Or does it
simply mean the Wikids don't understand C very well?
Clearly an opportunity for you Richard, to set the record straight.

Don't tempt me.
You have credentials enough to be accepted by Wiki I'm sure.

That would change as soon as I started deleting entire swathes of useless
material and told them to read a decent book about C and spend a few years
writing it properly before expressing an opinion on it.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

in comp.lang.c i read:

On 2005-12-24, Richard Heathfield <in*****@invalid.invalid> wrote:

Joe Wright said:

When was it that use of gets() became widely known as evil?

1988, I think.

Why did it make it into the standard, then?

because it was in wide use. see the rationale if you would like more
words.

--
a signature

Emmanuel Delahaye <em***@yourbranoos.fr> wrote:

we******@gmail.com a écrit :

Personally, I am waiting for the compiler that implements gets as the
following:

char * gets (char * s) {

.... remove (__FILE__);

return s;
}

BTW, I suppose that you want some [C99] 'inline'. If not, the effect
would be limited (the implementation file is probably not that close)

I don't think `inline' would help anything. Inline functions are
not expanded the same way as macros are, and `__FILE__' in above
code (after adding `inline') should still resolve to the name of
the implementation file.

#define gets(s) (remove(__FILE__), gets(s))

--
Stan Tobias
mailx `echo si***@FamOuS.BedBuG.pAlS.INVALID | sed s/[[:upper:]]//g`

In article <do**********@nwrdmz03.dmz.ncs.ea.ibs-infra.bt.com>,
Richard Heathfield <in*****@invalid.invalid> wrote:
....

Or even simple partisanship. Wikipedia shows considerable dislike for C, but
is very positive about, say, C++, Python, and Lisp.

I don't see where you get this. I read the Wikipedia entry for C, and,
yes, it includes a Critcism section. I consider the article quite
balanced, and it sounds like you are saying that any criticism is bad.
This is the position one expects from defenders of a faith. A "you're
either with us or against us" mentality.

I think we all agree that C has its problems. That, first of all, any
language that was designed to be "portable assembler" is going to have
problems in the safety department. And second, that the existence of all
this "UB" in the language definition (I.e., that which is the primary
subject of this newsgroup) is not a Good Thing. Necessary, of course,
given what C is, but not in any sense desirable in the abstract.

I think it is entirely fair and reasonable (aye, in fact to not do so would
be irresponsible) to warn potential newcomers to the language of its
dangers.

In article <do**********@nwrdmz02.dmz.ncs.ea.ibs-infra.bt.com>,
Richard Heathfield <in*****@invalid.invalid> wrote:
....

That would change as soon as I started deleting entire swathes of useless
material and told them to read a decent book about C and spend a few years
writing it properly before expressing an opinion on it.

But that's precisely the problem - most (counted by sheer numbers - i.e.,
one human being, one vote) people who use C don't and never will use it
correctly. I think it is for them that the Wikipedia article is written.

Then, of course, there is also the universal phenomenon that whenever the
media (media of any nature, and yes, in today's world, that includes
Wikipedia) reports on *anything* that you (rhetorical "you") knows anything
about, they get it all wrong. Or, more precisely, all you see are the
errors. Just something we all have to live with.

In article <p4******************************@comcast.com>,
Joe Wright <jo********@comcast.net> wrote:
....

When was it that use of gets() became widely known as evil? I started C
fifteen or more years ago and it was evil then. Why are some now just
discovering it is evil? Is anyone listening?

Ah, I see. You are a newcomer to the language.

In article <11*************@corp.supernews.com>,
Gordon Burditt <go***********@burditt.org> wrote:
....

How
could anyone do so once the executable binary have been generated? I

Why don't you ask the FBI Computer Task Force?

Google for "Smashing the stack for fun and profit".

"Richard Heathfield" <in*****@invalid.invalid> wrote

That would change as soon as I started deleting entire swathes of useless
material and told them to read a decent book about C and spend a few years
writing it properly before expressing an opinion on it.

I once expressed scepticism about formal methods (my point was that usually
the formal method is so compex and burdensome that it is easier for a human
to write correct code first time than to follow the method in all its
intricacies).

Some supporter of formal methods said that I didn't have the experience to
make such an assertion.

I replied that I had been on a six month training course on formal methods.

"Ha," said the supporter of formal methods, "the people who devise these
methods have often spent twenty years developing them. And you are rejecting
them on the basis of a six month course."

The problem with that argument is that the number of six month courses I can
go on is strictly limited. I wouldn't say I am necessarily right about
formal methods, but I have a great deal of experience in programming. If
someone cannot convince me of the value of his approach in six months, then
I must have a powerful and qualified case that the approach is not, in fact,
valuable.