gets() is dead

[jacob navia]

In the discussion group comp.std.c Mr Gwyn wrote:

< quote >

.... gets has been declared an obsolescent feature and
deprecated, as a direct result of my submitting a DR about it
(which originally suggested a less drastic change). (The official
impact awaits wrapping up the latest batch of TCs into a formal
amending document, and getting it approved and published.)

< end quote >

This is a very positive development. After all those discussions,
reason prevailed and we got rid of that wart.

It *is* possible to influence the comitee as it seems.
This is good news.

jacob

[Gregor H.]

On Wed, 25 Apr 2007 01:02:04 +0200, jacob navia
<ja***@jacob.remcomp.frwrote:

>
< quote >

... gets has been declared an obsolescent feature and
deprecated, as a direct result of my submitting a DR about it
(which originally suggested a less drastic change). (The official
impact awaits wrapping up the latest batch of TCs into a formal
amending document, and getting it approved and published.)

< end quote >

R.I.P.
G.

--

E-mail: info<at>simple-line<Punkt>de

[Keith Thompson]

Gregor H. <nomail@invalidwrites:

On Wed, 25 Apr 2007 01:02:04 +0200, jacob navia
<ja***@jacob.remcomp.frwrote:

>< quote >

... gets has been declared an obsolescent feature and
deprecated, as a direct result of my submitting a DR about it
(which originally suggested a less drastic change). (The official
impact awaits wrapping up the latest batch of TCs into a formal
amending document, and getting it approved and published.)

< end quote >

R.I.P.

It's not dead yet. "Deprecated" merely means that it can be
considered for removal in the next version of the standard (which
presumably will be released some time after C99 actually catches on).
Conforming implementations are still required to support gets().

But this is the first step in getting rid of it.

--
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."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Richard Heathfield]

Keith Thompson said:

<snip>

Conforming implementations are still required to support gets().

But this is the first step in getting rid of it.

Surely the first step was the continual rage and horror expressed at its
prolonged survival, over a period of many years, by a great many
people, until ISO were embarrassed by their own inadequate explanations
for its continued existence?

Next stop: unmodified %s in scanf.

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

[Keith Thompson]

Richard Heathfield <rj*@see.sig.invalidwrites:

Keith Thompson said:

<snip>

>Conforming implementations are still required to support gets().

But this is the first step in getting rid of it.

Surely the first step was the continual rage and horror expressed at its
prolonged survival, over a period of many years, by a great many
people, until ISO were embarrassed by their own inadequate explanations
for its continued existence?

Yeah, that too.

--
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."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Eric Sosman]

Richard Heathfield wrote:

Keith Thompson said:

<snip>

>Conforming implementations are still required to support gets().

But this is the first step in getting rid of it.

Surely the first step was the continual rage and horror expressed at its
prolonged survival, over a period of many years, by a great many
people, until ISO were embarrassed by their own inadequate explanations
for its continued existence?

Next stop: unmodified %s in scanf.

.... along with unrestricted "[%", I guess. But there's no
compelling reason to remove either of them from sscanf() ...

--
Eric Sosman
es*****@acm-dot-org.invalid

[CBFalconer]

Richard Heathfield wrote:

Keith Thompson said:

<snip>

>Conforming implementations are still required to support gets().

But this is the first step in getting rid of it.

Surely the first step was the continual rage and horror expressed
at its prolonged survival, over a period of many years, by a great
many people, until ISO were embarrassed by their own inadequate
explanations for its continued existence?

Next stop: unmodified %s in scanf.

Not needed, it can be handled. More useful would be inclusion of
generic routines for numerical input from streams without buffers.

--
<http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>
<http://www.securityfocus.com/columnists/423>
<http://www.aaxnet.com/editor/edit043.html>
cbfalconer at maineline.net

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

[Al Balmer]

On Wed, 25 Apr 2007 01:13:08 +0200, Gregor H. <nomail@invalidwrote:

>On Wed, 25 Apr 2007 01:02:04 +0200, jacob navia
<ja***@jacob.remcomp.frwrote:

You snipped one rather important line:

"In the discussion group comp.std.c Mr Gwyn wrote:"

>>
< quote >

... gets has been declared an obsolescent feature and
deprecated, as a direct result of my submitting a DR about it
(which originally suggested a less drastic change). (The official
impact awaits wrapping up the latest batch of TCs into a formal
amending document, and getting it approved and published.)

< end quote >

R.I.P.

Your editing made it appear that this was a quote from Jacob Navia.

Incidentally, I am unable to find this article with a Google Groups
search of comp.std.c. Does anyone have a link?

--
Al Balmer
Sun City, AZ

[Tor Rustad]

jacob navia wrote:

[...]

This is a very positive development. After all those discussions,
reason prevailed and we got rid of that wart.

These days, there should be no experienced C programmers using gets()
in security sensitive programs anyway, so I don't see the big fuzz about
this.

I have done a number of C code audits in safety-critical systems, and never
seen a single gets(), and didn't expect such a trivial bug either.

Who cares what students use?

I don't.

[Richard Heathfield]

Al Balmer said:

<snip>

Incidentally, I am unable to find this article[*] with a Google Groups
search of comp.std.c. Does anyone have a link?

Message-ID: <46***************@null.net>

[* An article by Doug Gwyn in comp.std.c, saying that gets() will be
deprecated in the next Standard.]

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

[Kenny McCormack]

In article <Q4*********************@telenor.com>,
Tor Rustad <to****@online.nowrote:

>jacob navia wrote:

[...]

>This is a very positive development. After all those discussions,
reason prevailed and we got rid of that wart.

It's the sort of thing that gets people in this ng hot.

>These days, there should be no experienced C programmers using gets()
in security sensitive programs anyway, so I don't see the big fuzz about
this.

I'd have said: no experienced C programmers using gets()
and left it at that. According to the ng regs, everything is "security
sensitive", so including that text is superfluouos.

>I have done a number of C code audits in safety-critical systems, and never
seen a single gets(), and didn't expect such a trivial bug either.

Who cares what students use?

I don't.

The anal-retentive freaks in this ng obviously do.
They've got nothing else in their lives, that much is clear.

[Ben Pfaff]

Richard Heathfield <rj*@see.sig.invalidwrites:

Al Balmer said:

>Incidentally, I am unable to find this article[*] with a Google Groups
search of comp.std.c. Does anyone have a link?

Message-ID: <46***************@null.net>

[* An article by Doug Gwyn in comp.std.c, saying that gets() will be
deprecated in the next Standard.]

Indeed, I can't find this via Google. But my local news server
has it. See below:

----------------------------------------------------------------------

From: "Douglas A. Gwyn" <DA****@null.net>
Subject: Re: security enhacement to C runtime library (XXX_s)
Newsgroups: comp.std.c
Date: Tue, 24 Apr 2007 21:47:36 GMT
Organization: U.S. Army Research Laboratory

we******@gmail.com wrote:

On Apr 22, 1:50 pm, "Douglas A. Gwyn" <[e-mail]:

The supposed advantage is that buffer overuns are under control,
not undefined behavior.

Now explain to me what can you really in a practical sense do about
this. If C had exception handling, then you could make a case, but it
doesn't so? You're going to call exit(-1) instead? I hope you saved
all your open documents in the program.

Because the behavior is controlled, you can safely save the state
of the work files, etc. Indeed, you can even simulate throwing an
exception by invoking jongjmp to regain control at a convenient
point in the overall algorithm. There are several implementations
of nested exception handling packages in Standard C.

With undefined behavior, you typically get a random crash leaving
data in a corrupted state, or worse yet get exploited by a "hacker"
who uses the overrun for nefarious purposes under *his* control.

Thus creating a new code synchronization issue. Congratulations. You
don't have any mathematicians (people who understand what a
mathematical closure is I mean) or people who have used Ruby, or
Python on the committee do you?

Sure we do. I know it's hard to believe that smart people could
come to any conclusion different from the one you come up with,
but it happens. Often it is because they are balancing a different
set of trade-offs or at least assigning different weights to them.

I had major problems that prevented me from considering contributing
to the ANSI standard:

If you don't participate, how do you expect to impact the outcome?

1) You are not open to the idea of *TAKING THINGS OUT* of the standard
library.

Unless there is really strong justification, altering the behavior
of features which have been relied upon as guaranteed to be supported
on every conforming implementation (including dropping the guarantee
of their existence) does a disservice to the huge amount of existing
code that relies on the guarantees. Therefore, there is *rightly* a
strong predisposition on the part of the standards body to maintain
existing interfaces. However, ...

2) You have overtly distorted reality in your C rationale in the past
to cover up for the embarrassment that is gets().

.... actually, gets has been declared an obsolescent feature and
deprecated, as a direct result of my submitting a DR about it
(which originally suggested a less drastic change). (The official
impact awaits wrapping up the latest batch of TCs into a formal
amending document, and getting it approved and published.)

3) If I were to propose Bstrlib for inclusion into the standard, and
it were to be accepted, it would *WORSEN* Bstrlib, because it would be
included by some/most compiler vendors in a closed-source manner. One
of Bstrlib's capabilities relies on the fact that it is open source
(replaceable allocation functions), and the security statement is
meaningless unless the source is available. So I declined the
potential wide-spread notoriety and usage I might have gotten for
Bstrlib if it were accepted (but lets be honest, you guys would not
have given it a fair shake anyways) in exchange for retaining its
status for maximal capability.

When submitted appropriately within the process, proposals are taken
quite seriously and are given fair consideration. A lot of what has
been standardized started out as such proposals. Of course, they had
active participants promoting, explaining, and shepherding them.

4) When I have made suggestions of proposals in the past I have been
met with nothing but derision from you people. There was also an
excellent and really necessary time generalization proposal (I don't
remember who made it, but it was from a regular here; Dave Tribble
maybe?). I don't see that proposal in the current TR. Its obvious
you people just don't care about important capability issues.

I doubt that anything you submitted for consideration by WG14 has
"met with derision". There was in fact an extended time function
proposal that spun off from an earlier proposal which had been found
to have problems too late in the C99 revision process to make it into
the last version of the standard. Tribble has indeed been working to
refine and improve that, although so far as I recall it has not been
proposed as a Work Item, which would be necessary for the committee
to being working on a TR in that regard. Of course it is unrelated
to the buffer-limits TR.

[Richard Tobin]

In article <8f********************************@4ax.com>,
Al Balmer <al******@att.netwrote:

>Incidentally, I am unable to find this article with a Google Groups
search of comp.std.c. Does anyone have a link?

I can't find anything I posted in the last day. I think it must be a
Google problem.

-- Richard
--
"Consideration shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.

[Christopher Benson-Manica]

Tor Rustad <to****@online.nowrote:

Who cares what students use?

Some students graduate. Handing them gets() is like handing them
matches and hoping they don't get anywhere near the flammables.

--
C. Benson Manica | I *should* know what I'm talking about - if I
cbmanica(at)gmail.com | don't, I need to know. Flames welcome.

[Charlton Wilbur]

>>>>"CBM" == Christopher Benson-Manica <at***@faeroes.freeshell.orgwrites:

CBMSome students graduate. Handing them gets() is like handing
CBMthem matches and hoping they don't get anywhere near the
CBMflammables.

It's considerably easier to deal with recent graduates if you don't
have to beat bad habits out of them before instilling good habits --
and even easier still if they come with good habits instilled.

Charlton
--
Charlton Wilbur
cw*****@chromatico.net

[Al Balmer]

On Wed, 25 Apr 2007 16:53:23 +0000, Richard Heathfield
<rj*@see.sig.invalidwrote:

>Al Balmer said:

<snip>

>Incidentally, I am unable to find this article[*] with a Google Groups
search of comp.std.c. Does anyone have a link?

Message-ID: <46***************@null.net>

[* An article by Doug Gwyn in comp.std.c, saying that gets() will be
deprecated in the next Standard.]

Thanks, Richard. I don't usually read the group. For some reason,
Google couldn't find the message, even searching for an exact phrase.
Probably it takes some time to get indexed.

--
Al Balmer
Sun City, AZ

[Tor Rustad]

Kenny McCormack wrote:

In article <Q4*********************@telenor.com>,
Tor Rustad <to****@online.nowrote:

>>These days, there should be no experienced C programmers using gets()
in security sensitive programs anyway, so I don't see the big fuzz about
this.

I'd have said: no experienced C programmers using gets()
and left it at that. According to the ng regs, everything is "security
sensitive", so including that text is superfluouos.

Well, it's not, there is no problem using gets(), when the programmer
control the input.

For example, when writing a quick-and-short-lived test module, which is
needed only during development.

[Default User]

Ben Pfaff wrote:

Richard Heathfield <rj*@see.sig.invalidwrites:

Al Balmer said:

Incidentally, I am unable to find this article[*] with a Google

Groups >search of comp.std.c. Does anyone have a link?

Message-ID: <46***************@null.net>

[* An article by Doug Gwyn in comp.std.c, saying that gets() will
be deprecated in the next Standard.]

Indeed, I can't find this via Google. But my local news server
has it. See below:

Google is apparently screwed up today. That's leading many GG users
reposting because they think messages didn't go out.

We're now at the "when Google coughs, usenet gets a cold" state.

Brian

[Dave Vandervies]

In article <Xu*********************@telenor.com>,
Tor Rustad <to********@hotmail.comwrote:

>Well, it's not, there is no problem using gets(), when the programmer
control the input.

For example, when writing a quick-and-short-lived test module, which is
needed only during development.

The problem with that is that quick-and-short-lived code usually isn't.
dave

--
Dave Vandervies dj******@csclub.uwaterloo.ca

Should I let the cat walk over the keyboard to select the compiler?
--CBFalconer in comp.lang.c

[Christopher Benson-Manica]

Tor Rustad <to********@hotmail.comwrote:

Well, it's not, there is no problem using gets(), when the programmer
control the input.

For example, when writing a quick-and-short-lived test module, which is
needed only during development.

I don't agree. Very few things are as quick-and-short-lived as they
are originally intended to be. It isn't a great leap from a simple
test to code that gets e-mailed to someone else to demonstrate that X
is broken to code that someone else may cut and paste without paying
attention. I would suggest that any source file making use of gets()
should be deleted within (at most) five minutes of creation.

--
C. Benson Manica | I *should* know what I'm talking about - if I
cbmanica(at)gmail.com | don't, I need to know. Flames welcome.

[Flash Gordon]

Tor Rustad wrote, On 25/04/07 19:35:

Kenny McCormack wrote:

>In article <Q4*********************@telenor.com>,
Tor Rustad <to****@online.nowrote:

>>These days, there should be no experienced C programmers using gets()
in security sensitive programs anyway, so I don't see the big fuzz about
this.

I'd have said: no experienced C programmers using gets()
and left it at that. According to the ng regs, everything is "security
sensitive", so including that text is superfluouos.

Well, it's not, there is no problem using gets(), when the programmer
control the input.

For example, when writing a quick-and-short-lived test module, which is
needed only during development.

The overhead of using fgets is pretty minimal even in that situation.
--
Flash Gordon

[Keith Thompson]

CBFalconer <cb********@yahoo.comwrites:

Richard Heathfield wrote:

>Keith Thompson said:

<snip>

>>Conforming implementations are still required to support gets().

But this is the first step in getting rid of it.

Surely the first step was the continual rage and horror expressed
at its prolonged survival, over a period of many years, by a great
many people, until ISO were embarrassed by their own inadequate
explanations for its continued existence?

Next stop: unmodified %s in scanf.

Not needed, it can be handled.

[snip]

I don't know what you mean by this. If you mean that eliminating
unmodified %s in scanf is not needed, can you explain? For example:

char s[N];
scanf("%s", s);

reads a (blank-delimited) word from stdin. If the user types, say,
2*N non-blank characters, it will invoke undefined behavior. How can
this be "handled" (other than by avoiding "%s")?

--
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."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Ian Collins]

Default User wrote:

>
Google is apparently screwed up today.

Today? You mean they fixed it before? ;)

--
Ian Collins.

[Default User]

Ian Collins wrote:

Default User wrote:

Google is apparently screwed up today.

Today? You mean they fixed it before? ;)

Screwed up worse than usual. It is, or was, failing to display new
posts for its users.

Brian

[CBFalconer]

Keith Thompson wrote:

CBFalconer <cb********@yahoo.comwrites:

>Richard Heathfield wrote:

.... snip ...

>>>
Next stop: unmodified %s in scanf.

Not needed, it can be handled.

[snip]

I don't know what you mean by this. If you mean that eliminating
unmodified %s in scanf is not needed, can you explain? For example:

char s[N];
scanf("%s", s);

reads a (blank-delimited) word from stdin. If the user types, say,
2*N non-blank characters, it will invoke undefined behavior. How
can this be "handled" (other than by avoiding "%s")?

By not using unmodified %s. That is a user choice. No such
available for gets.

--
<http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>
<http://www.securityfocus.com/columnists/423>
<http://www.aaxnet.com/editor/edit043.html>
cbfalconer at maineline.net

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

[Keith Thompson]

CBFalconer <cb********@yahoo.comwrites:

Keith Thompson wrote:

>CBFalconer <cb********@yahoo.comwrites:

>>Richard Heathfield wrote:

... snip ...

>>>>
Next stop: unmodified %s in scanf.

Not needed, it can be handled.

[snip]

I don't know what you mean by this. If you mean that eliminating
unmodified %s in scanf is not needed, can you explain? For example:

char s[N];
scanf("%s", s);

reads a (blank-delimited) word from stdin. If the user types, say,
2*N non-blank characters, it will invoke undefined behavior. How
can this be "handled" (other than by avoiding "%s")?

By not using unmodified %s. That is a user choice. No such
available for gets.

The suggestion, I think, is to disallow the use of "%s" with scanf.

Disallowing a particular argument value to a function is not as
straightforward as eliminating a function altogether, but the
rationale is the same. gets(..) cannot be used safely;
scanf("%s", ...) cannot be used safely.

--
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."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Malcolm McLean]

"Keith Thompson" <ks***@mib.orgwrote in message
news:ln************@nuthaus.mib.org...

CBFalconer <cb********@yahoo.comwrites:

>Keith Thompson wrote:

>>CBFalconer <cb********@yahoo.comwrites:
Richard Heathfield wrote:

... snip ...

>>>>>
Next stop: unmodified %s in scanf.

Not needed, it can be handled.
[snip]

I don't know what you mean by this. If you mean that eliminating
unmodified %s in scanf is not needed, can you explain? For example:

char s[N];
scanf("%s", s);

reads a (blank-delimited) word from stdin. If the user types, say,
2*N non-blank characters, it will invoke undefined behavior. How
can this be "handled" (other than by avoiding "%s")?

By not using unmodified %s. That is a user choice. No such
available for gets.

The suggestion, I think, is to disallow the use of "%s" with scanf.

Disallowing a particular argument value to a function is not as
straightforward as eliminating a function altogether, but the
rationale is the same. gets(..) cannot be used safely;
scanf("%s", ...) cannot be used safely.

And fgets() is in practise too difficult for any but the best programmers to
use safely.
--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

[Keith Thompson]

"Malcolm McLean" <re*******@btinternet.comwrites:

"Keith Thompson" <ks***@mib.orgwrote in message
news:ln************@nuthaus.mib.org...

[...]

>The suggestion, I think, is to disallow the use of "%s" with scanf.

Disallowing a particular argument value to a function is not as
straightforward as eliminating a function altogether, but the
rationale is the same. gets(..) cannot be used safely;
scanf("%s", ...) cannot be used safely.

And fgets() is in practise too difficult for any but the best
programmers to use safely.

Huh???

fgets() has limitations, but it doesn't pose anything like the danger
of gets() or scanf("%s", ...). It mishandles long lines by leaving
the remainder in the input stream, which is a minor inconvenience
compared to the undefined behavior of gets().

--
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."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Richard Heathfield]

Keith Thompson said:

"Malcolm McLean" <re*******@btinternet.comwrites:

<snip>

>And fgets() is in practise too difficult for any but the best
programmers to use safely.

Huh???

Quite. It's a ludicrous claim.

fgets() has limitations, but it doesn't pose anything like the danger
of gets() or scanf("%s", ...). It mishandles long lines by leaving
the remainder in the input stream, which is a minor inconvenience
compared to the undefined behavior of gets().

What else could fgets do with long lines, other than leave them in the
input stream, if it isn't allowed to call *alloc()?

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

[jaysome]

On Wed, 25 Apr 2007 01:02:04 +0200, jacob navia wrote:

In the discussion group comp.std.c Mr Gwyn wrote:

< quote >

... gets has been declared an obsolescent feature and
deprecated, as a direct result of my submitting a DR about it
(which originally suggested a less drastic change). (The official
impact awaits wrapping up the latest batch of TCs into a formal
amending document, and getting it approved and published.)

< end quote >

This is a very positive development. After all those discussions,
reason prevailed and we got rid of that wart.

It *is* possible to influence the comitee as it seems.
This is good news.

jacob

So, I guess the reasoning goes, in C0x or possibly even C1x, we'll all be
relieved of having to deal with gets()?

Will compiler vendors jump on the bandwagon of conforming to the latest
standard and forbid us to use gets(), just like they jumped on the
bandwagon of adopting the now-more-than-8-year-old C99 standard, and
allowed us to use "//" comments and declare variables in-line and use some
great keywords like "restrict"?

And if they do, will we all jump on their bandwagon and switch to their
latest and greatest C0x or C1x compiler--just like we all jumped on the
C99 compiler bandwagon--just so that we can take advantage of the great
feature of deprecating gets()?

I think not.

Although Mr. Gwyn's intentions are laudable, his connection with reality
is arguably questionable, and regrettably about 17 years too late.

Best regards
--
jay

[Keith Thompson]

Richard Heathfield <rj*@see.sig.invalidwrites:

Keith Thompson said:

[...]

>fgets() has limitations, but it doesn't pose anything like the danger
of gets() or scanf("%s", ...). It mishandles long lines by leaving
the remainder in the input stream, which is a minor inconvenience
compared to the undefined behavior of gets().

What else could fgets do with long lines, other than leave them in the
input stream, if it isn't allowed to call *alloc()?

Well, it could discard them, but that would be dumb.

--
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."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Richard Bos]

Tor Rustad <to********@hotmail.comwrote:

Well, it's not, there is no problem using gets(), when the programmer
control the input.

s/when/if/.

For example, when writing a quick-and-short-lived test module, which is
needed only during development.

You clearly do not have cats, children, _or_ typo-prone fingers.

Richard

[Kenny McCormack]

In article <46*****************@news.xs4all.nl>,
Richard Bos <rl*@hoekstra-uitgeverij.nlwrote:

>Tor Rustad <to********@hotmail.comwrote:

>Well, it's not, there is no problem using gets(), when the programmer
control the input.

s/when/if/.

>For example, when writing a quick-and-short-lived test module, which is
needed only during development.

You clearly do not have cats, children, _or_ typo-prone fingers.

Richard

See what I mean about "anal-retentive freaks without lives" ???

[websnarf]

On Apr 25, 11:35 am, Tor Rustad <[e-mail]:

Kenny McCormack wrote:

In article <[e-mail]>,
Tor Rustad <[e-mail]:

>These days, there should be no experienced C programmers using gets()
in security sensitive programs anyway, so I don't see the big fuzz about
this.

I'd have said: no experienced C programmers using gets()
and left it at that. According to the ng regs, everything is "security
sensitive", so including that text is superfluouos.

Well, it's not, there is no problem using gets(), when the programmer
control the input.

For example, when writing a quick-and-short-lived test module, which is
needed only during development.

As if we need further proof of just how dangerous gets() is. (James
Dow Allen has posted similar sentiments here in the past.) Even the
face of knowing exactly what's wrong with it, people claim its usable.

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

[Eric Sosman]

Malcolm McLean wrote:

>
And fgets() is in practise too difficult for any but the best
programmers to use safely.

You're setting the "best" bar awfully low.

--
Eric Sosman
es*****@acm-dot-org.invalid

[Chris Dollin]

Malcolm McLean wrote:

And fgets() is in practise too difficult for any but the best programmers to
use safely.

I think that's absurd. Do you have a reason for this interesting point of view?

--
"Go not to the Drazi for counsel, Unsaid /Babylon 5/
for they will answer both 'green' and 'purple'."

Hewlett-Packard Limited registered no:
registered office: Cain Road, Bracknell, Berks RG12 1HN 690597 England

[Richard Heathfield]

Malcolm McLean said:

<snip>

And fgets() is in practise too difficult for any but the best
programmers to use safely.

Oh dear. I sure hope I'm a counter-example, because otherwise I've been
using fgets() unsafely for years.

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

[Francine.Neary]

On Apr 25, 12:02 am, jacob navia <[e-mail]:

This is a very positive development. After all those discussions,
reason prevailed and we got rid of that wart.

It *is* possible to influence the comitee as it seems.
This is good news.

I wouldn't say it's good news. Firstly, it will break a lot of old
code if it's dropped. Secondly, gets() is completely safe *as long as
_you_ control the data passed to it*. Of course it should never be
used in production code, but for private/development/toy code I find
it extremely useful.

jacob

[Eric Sosman]

jaysome wrote On 04/26/07 03:13,:

On Wed, 25 Apr 2007 01:02:04 +0200, jacob navia wrote:

>>In the discussion group comp.std.c Mr Gwyn wrote:

< quote >

... gets has been declared an obsolescent feature and
deprecated, as a direct result of my submitting a DR about it
(which originally suggested a less drastic change). (The official
impact awaits wrapping up the latest batch of TCs into a formal
amending document, and getting it approved and published.)

< end quote >

This is a very positive development. After all those discussions,
reason prevailed and we got rid of that wart.

It *is* possible to influence the comitee as it seems.
This is good news.

jacob

So, I guess the reasoning goes, in C0x or possibly even C1x, we'll all be
relieved of having to deal with gets()?

Will compiler vendors jump on the bandwagon of conforming to the latest
standard and forbid us to use gets(), just like they jumped on the
bandwagon of adopting the now-more-than-8-year-old C99 standard, and
allowed us to use "//" comments and declare variables in-line and use some
great keywords like "restrict"?

And if they do, will we all jump on their bandwagon and switch to their
latest and greatest C0x or C1x compiler--just like we all jumped on the
C99 compiler bandwagon--just so that we can take advantage of the great
feature of deprecating gets()?

I think not.

Although Mr. Gwyn's intentions are laudable, his connection with reality
is arguably questionable, and regrettably about 17 years too late.

What part of the quoted text is connected tenuously to
reality? It says that "gets has been declared an obsolescent
feature and deprecated." Do you have a reason to believe
this is an inaccurate description of the state of affairs?

It was you, not Doug Gwyn, who suggested that the action
of the Committee would "relieve" the world of gets(). It was
you, not Gwyn, who described the miraculous consequences of
gets()' forthcoming status. It is you, not Gwyn, who are
peddling fantasy.

--
Er*********@sun.com

[Richard Heathfield]

Fr************@googlemail.com said:

On Apr 25, 12:02 am, jacob navia <[e-mail]:

>This is a very positive development. After all those discussions,
reason prevailed and we got rid of that wart.

It *is* possible to influence the comitee as it seems.
This is good news.

I wouldn't say it's good news. Firstly, it will break a lot of old
code if it's dropped.

No, it won't break any old code that was not already broken.

Secondly, gets() is completely safe *as long as
_you_ control the data passed to it*.

And you can't guarantee that you do.

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

[Gregor H.]

On 26 Apr 2007 09:53:18 -0700, Fr************@googlemail.com wrote:

>>
This is a very positive development. After all those discussions,
reason prevailed and we got rid of that wart.

It *is* possible to influence the comitee as it seems.
This is good news.

I wouldn't say it's good news. Firstly, it will break a lot of old
code if it's dropped.

Which is rather good news, given that the code you are talking about
makes use of "gets()" --- which is an inherently unsafe function.

>
Secondly, gets() is completely safe *as long as _you_ control the
data passed to it*.

Hear, hear. Well, sure, a gun is also completely safe as long you do
not aim at people with it.

>
Of course it should never be used in production code, but for
private/development/toy code I find it extremely useful.

It's extremely idiotic to have such a function in the first place,
even if only interested in "private/development/toy code" ...

Why do you think that

fgets(buffer, MAXBUF, stdin);

is less useful than

gets(buffer);

???
And if you have problems with the '\n' read in into the buffer, then
you might just add the code

char *pszTemp;
if ((pszTemp = strchr(buffer, '\n')) != NULL)
*pszTemp = '\0';

Done.
G.

--

E-mail: info<at>simple-line<Punkt>de

[Flash Gordon]

Fr************@googlemail.com wrote, On 26/04/07 17:53:

On Apr 25, 12:02 am, jacob navia <[e-mail]:

>This is a very positive development. After all those discussions,
reason prevailed and we got rid of that wart.

It *is* possible to influence the comitee as it seems.
This is good news.

I wouldn't say it's good news.

I and many others here disagree.

Firstly, it will break a lot of old
code if it's dropped.

Most people here (even those who have argued for keeping gets) think
that it is only useful for quick throw-away programs (which are not a
problem as they are going to be thrown away anyway) and very specialised
situations (which being very specialised do not occur often and so do
not make up a lot of code). Any other code needs to be fixed anyway, so
the sooner it will not build the better since it will force it to be
fixed or discarded.

Secondly, gets() is completely safe *as long as
_you_ control the data passed to it*.

In such a situation you know the size of the buffer you have allocated
so is it really such a big problem to do:
fgets(buffer,sizeof buffer,stdin);
or
fgets(buffer,BUFFER_SIZE,stdin);

You could even write a macro
#define GETS(buffer) fgets(buffer,sizeof buffer,stdin)
which would be suitable for most usage.

Of course it should never be
used in production code, but for private/development/toy code I find
it extremely useful.

See above for easy ways to live without it. If the buffer is not large
enough you are likely to find it easier to debug since the results will
be more predictable, if it is large enough it just means you have to
deal with the newline left in the buffer. So you could do:
#define GETS(buffer) ((fgets(buffer,sizeof buffer,stdin)!=NULL)? \
(buffer[strcspn(buffer,"\n")]=0,buffer):NULL)

Obviously you do not pass a pointer to this macro. It can be used as in:
#include <stdio.h>
#include <string.h>

#define GETS(buffer) ((fgets(buffer,sizeof buffer,stdin)!=NULL)? \
(buffer[strcspn(buffer,"\n")]=0,buffer):NULL)

int main(void)
{
char buf[10];
GETS(buf);
printf("'%s'\n",buf);
GETS(buf);
printf("'%s'\n",buf);
return 0;
}

markg@brenda:~$ gcc -ansi -pedantic -Wall -Wextra -O t.c
markg@brenda:~$ ./a.out

''

''
markg@brenda:~$ ./a.out
1
'1'

''
markg@brenda:~$ ./a.out
12345678
'12345678'

''
markg@brenda:~$ ./a.out
123456789
'123456789'
''
markg@brenda:~$ ./a.out
1234567890
'123456789'
'0'
markg@brenda:~$

Easily good enough for a throwaway program wanting gets type
functionality. I will even hereby grant everyone the permission to use
the code illustrated herein for any code of there own for any purpose
under any license with one exception. If you are publishing my idea
outside Usenet then you need my permission and inside Usenet you need to
acknowledge it as mine unless you can find prior art.
--
Flash Gordon

[Richard Heathfield]

Flash Gordon said:

<snip>

I will even hereby grant everyone the permission to use
the code illustrated herein for any code of there own for any purpose
under any license with one exception. If you are publishing my idea
outside Usenet then you need my permission and inside Usenet you need
to acknowledge it as mine unless you can find prior art.

Very generous, Flash, but if it's all the same to you, I'll pass. :-)
--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

[Flash Gordon]

Eric Sosman wrote, On 26/04/07 18:17:

<snip>

reality? It says that "gets has been declared an obsolescent
feature and deprecated." Do you have a reason to believe

I think it would be nice if the standard mandated emitting a diagnostic
for the use of any feature declared in the standard as obsolescent
and/or deprecated. Note that I am NOT saying it should fail to
compile/link, just that a diagnostic should be issued.
--
Flash Gordon

[Flash Gordon]

Richard Heathfield wrote, On 26/04/07 18:53:

Flash Gordon said:

<snip>

>I will even hereby grant everyone the permission to use
the code illustrated herein for any code of there own for any purpose
under any license with one exception. If you are publishing my idea
outside Usenet then you need my permission and inside Usenet you need
to acknowledge it as mine unless you can find prior art.

Very generous, Flash, but if it's all the same to you, I'll pass. :-)

I'm sure you have a suitable routine for situations where other might
consider using gets anyway :-)

I would also not be surprised if something similar has been posted in
the past.
--
Flash Gordon

[Dave Vandervies]

In article <kf************@news.flash-gordon.me.uk>,
Flash Gordon <sp**@flash-gordon.me.ukwrote:

>Eric Sosman wrote, On 26/04/07 18:17:

<snip>

>reality? It says that "gets has been declared an obsolescent
feature and deprecated." Do you have a reason to believe

I think it would be nice if the standard mandated emitting a diagnostic
for the use of any feature declared in the standard as obsolescent
and/or deprecated. Note that I am NOT saying it should fail to
compile/link, just that a diagnostic should be issued.

The standard makes no distinction between a diagnostic that causes
translation to be aborted and one that allows it to continue. Many
implementations make this distinction between "warnings" and "errors";
when invoked in conforming mode, such an implementation may issue either
a "warning" or an "error" for a syntax error or constraint violation
(and most do some of each), but only a "warning" for diagnostics not
required by the standard.

I don't think that getting required non-fatal warnings for obsolescent
or deprecated features would be worth creating that distinction in the
language implementation, especially since most reasonable implementations
already *do* issue non-fatal warnings for them.
dave

--
Dave Vandervies dj******@csclub.uwaterloo.ca
[...]then stick a fake rock on top of the mast to cover the dish. Then the
dish isn't the unslightly thing seen from the road, and there's nothing in
the CCR banning fake aerial rocks. --Peter H. Coffin in the SDM

[Dave Vandervies]

In article <f0**********@rumours.uwaterloo.ca>,
Dave Vandervies <dj******@caffeine.csclub.uwaterloo.cawrote:

>I don't think that getting required non-fatal warnings for obsolescent
or deprecated features would be worth creating that distinction in the
language implementation, especially since most reasonable implementations

^^^^^^^^^^^^^^

>already *do* issue non-fatal warnings for them.

I meant "in the language specification", of course.

But even in this correction it took me three tries to convince my fingers
of that for some reason.
dave

--
Dave Vandervies dj******@csclub.uwaterloo.ca
[...]then stick a fake rock on top of the mast to cover the dish. Then the
dish isn't the unslightly thing seen from the road, and there's nothing in
the CCR banning fake aerial rocks. --Peter H. Coffin in the SDM

[Default User]

Richard Heathfield wrote:

Malcolm McLean said:

<snip>

And fgets() is in practise too difficult for any but the best
programmers to use safely.

Oh dear. I sure hope I'm a counter-example, because otherwise I've
been using fgets() unsafely for years.

As he humbly discards the possibility that he's one of the best
programmers.


Brian

[Dave Vandervies]

In article <59*************@mid.individual.net>,
Default User <de***********@yahoo.comwrote:

>Richard Heathfield wrote:

>Malcolm McLean said:

<snip>

And fgets() is in practise too difficult for any but the best
programmers to use safely.

Oh dear. I sure hope I'm a counter-example, because otherwise I've
been using fgets() unsafely for years.

As he humbly discards the possibility that he's one of the best
programmers.

I can't speak for him, but I suspect his response to that would be
similar to mine:

I like to think I'm good. If I tried hard enough, I could probably even
dig up supporting evidence for above average. But if I'm "one of the
best", we're all in trouble.

And I, too, have apparently been using fgets unsafely for years.
dave

--
Dave Vandervies dj******@csclub.uwaterloo.ca
[...]then stick a fake rock on top of the mast to cover the dish. Then the
dish isn't the unslightly thing seen from the road, and there's nothing in
the CCR banning fake aerial rocks. --Peter H. Coffin in the SDM

[Malcolm McLean]

"Chris Dollin" <ch**********@hp.comwrote in message
news:f0**********@murdoch.hpl.hp.com...

Malcolm McLean wrote:

>And fgets() is in practise too difficult for any but the best programmers
to
use safely.

I think that's absurd. Do you have a reason for this interesting point of
view?

You've provided your own evidence.
You can't articulate why fgets() is dangerous, or why it could be considered
dangerous if you persist in disagreeing with me. A threat you can't
recognise is much more deadly than one that you can.

--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm