scanf (yes/no) - doesn't work + deprecation errors scanf, fopen etc.

[Joe Wright]

But of course it can: you just need to be careful when using a program that
calls gets().

I don't see a smiley. Are you serious? How is one 'careful' when using a
program which calls gets()?

This is one of the oldest talking points in this newsgroup. The
overwhelming consensus is that gets() cannot be used safely where you do
not control the input to stdin. Dan Pop said he could use it safely but
only on a specific hardware of his own design. That doesn't count.

 

[Wojtek Lerch]

On most systems that would only be a danger if the code is running with
rights that you don't want the other users / internet users to be able
to gain access to. You certainly can't get root from a non-setuid
program.

Well, there also is the theoretical possibility that after gets() overwrites
the return address on the stack, your program happens to jump to the
"remove" function, and the memory that the function thinks its argument
points to happens to contain a sequence of bytes that matches the name of an
important file.

And let's not forget about the possibility that the person running your
program is your boss and that seeing it crash may affect his decision about
whether to give you a raise.

 

[Wojtek Lerch]

I don't see a smiley. Are you serious? How is one 'careful' when using a
program which calls gets()?

By avoiding to type very long strings into its stdin, obviously.

This is one of the oldest talking points in this newsgroup. The
overwhelming consensus is that gets() cannot be used safely where you do
not control the input to stdin.

Well, exactly. It can be used safely, if you do control the input to stdin.

 

[Douglas A. Gwyn]

I don't believe that removing it from the standard would cause any
harm in the real world.

Nor benefit.
It would actually cause new problems due to removal of the
declaration from <stdio.h>.
Specification of an interface in the standard doesn't imply
blessing its use in contexts where it isn't appropriate;
if it did, we'd have to remove all the interfaces.
Further, so long as it is easy to find the specification for
gets(), it can readily be used as an example when teaching
student programmers about overrun issues, so it might make
a positive net contribution to safer programming.
Certainly, anyone using gets() where it could pose a safety
problem (which contrary to trendy claims is *not* everywhere)
must be so oblivious to the relevant issues that even the
(unlikely) total ansence of the function from his development
environment wouldn't make him an appreciably safer programmer.

 

[Douglas A. Gwyn]

How about making attempted use of gets() a required diagnostic?
or changing the standard to allow gets() to print an
implementation-defined string to stderr before accepting input

No, you would be mandating breaking programs that did not
exhibit a problem before, perhaps because they used gets()
only in contexts where it was sufficiently safe. Causing
other people problems in order to promote your own political
agenda is one of the banes of modern life, and we don't need
to encourage more of that.

 

[Francis Glassborow]

Removing it before deprecation would be mean.

Well I think that the meanness is in not removing it. I get tired of the
number of books for novices that still use gets(). As long as it is in
the Standard authors will just argue that they are using the standard
library.

If we removed it tomorrow, not a single program would fail but we could
condemn those that continue to teach its use and they would have
absolutely no defence.

 

[Francis Glassborow]

The usual standards mechanism is for a newly issued revision
of the standard to flag the item as a "deprecated feature",
which means that it must still be supported by conforming
implementations at least until the next major revision of
the standard. That typically means 10 years at least before
implementations need to do anything differently.

You mean like we did with implicit int?

If something is so bad that the consensus is that it can never be used
safely we should not be endorsing it in any way. We should have the
courage to tell the world today that gets() will not be in the next
release of the C Standard whenever it is that we decide to produce one.

 

[Douglas A. Gwyn]

%lf now allowed for doubles with printf.

That was actually in the reference implementation of the
base library, and seems to have been intended to permit
wider sharing of the same format string by printf and
scanf.

return statement no longer required in main.

Yes, and there was heated debate about that. The only
real selling point for the change is that it retroactively
sanctioned that usage in the earlier examples in K&R2
(until section 1.7), which failed to be strictly
conforming programs only in that one respect. Apparently
requiring all conforming implementations to make those
examples work without weird undefined behavior (such as
system messages saying that the programs report failure)
was considered a worthy goal. Anyway, as 1.7 shows, it
wasn't sloppiness when K&R did it that way. (We even had
a discussion about the matter when I reviewed a draft of
the book before it was published.)

 

[kuyper]

Nor benefit.
It would actually cause new problems due to removal of the
declaration from <stdio.h>.

It would cause certain programs to fail at compile time that should
fail. I don't see that as a seriouis problem, particularly since the
function will always be available as non-standard extension, even if it
is someday removed from the standard library.

Specification of an interface in the standard doesn't imply
blessing its use in contexts where it isn't appropriate;

No, but it implies, in this case falsely, that there are at least some
contexts where it is appropriate. You can put together contrived cases
where gets() is actually safe, but there are none where it's
appropriate, when fgets() is available.

Certainly, anyone using gets() where it could pose a safety
problem (which contrary to trendy claims is *not* everywhere)

It's close enough to everywhere. While there are non-portable ways in
which a program can have sufficient control over it's standard input to
allow safe use of gets(), the standard should mainly be concerned with
the needs of portable code, where no such control is possible.

must be so oblivious to the relevant issues that even the
(unlikely) total ansence of the function from his development
environment wouldn't make him an appreciably safer programmer.

It would make his programs marginally safer. In the absence of good
reasons for not doing it, even that marginal improvement would still be
worthwhile.

 

[Keith Thompson]

No, you would be mandating breaking programs that did not
exhibit a problem before, perhaps because they used gets()
only in contexts where it was sufficiently safe. Causing
other people problems in order to promote your own political
agenda is one of the banes of modern life, and we don't need
to encourage more of that.

I don't believe that there are a significant number of programs that
use gets() safely. I believe there are a plethora of programs that
use it unsafely. Leaving Jordan's suggestions aside, simply removing
gets() from the standard would not break a single one of them.

 

[Keith Thompson]

Nor benefit.

Obviously, I disagree.

Prior to the ANSI standard, strdup() was commonly part of the C
library, right? Why did the C89 standard include gets() but not
strdup()? If gets() had been dropped from the standard back in 1989,
would that have been a bad thing; would you have (or did you) argue
for including it?

 

[Jordan Abel]

No, you would be mandating breaking programs that did not
exhibit a problem before, perhaps because they used gets()
only in contexts where it was sufficiently safe.

What contexts are those?

Causing
other people problems in order to promote your own political
agenda is one of the banes of modern life, and we don't need
to encourage more of that.

A required diagnostic does NOT mean a program must fail to compile. Many
implementations _DO_ emit a diagnostic if they detect that gets() is
being used.

 

[Jordan Abel]

That was actually in the reference implementation of the
base library, and seems to have been intended to permit
wider sharing of the same format string by printf and
scanf.

Where is this "reference implementation"?

 

[Jordan Abel]

Yes, and there was heated debate about that. The only real selling
point for the change is that it retroactively sanctioned that usage in
the earlier examples in K&R2 (until section 1.7), which failed to be
strictly conforming programs only in that one respect.

Ironic, then, that this was the same version of the standard that
removed implicit int.

Apparently requiring all conforming implementations to make those
examples work without weird undefined behavior (such as system

Well, at least it's a constraint violation now.

 

[Micah Cowan]

Certainly, anyone using gets() where it could pose a safety
problem (which contrary to trendy claims is *not* everywhere)

^^^^^^

"You keep using that word. I do not think it means what you think it
means."

You also keep talking about the fact that it is not truly impossible
to use gets() safely (given certain nonportable situations). While
this may be literally true, I strongly suspect that we could count the
number of totally safe usages using our hands. Even when it really
/is/ safe, the *huge* majority of safety-conscious coders will /still/
refuse to use it. I expect that the safe use of it is so incredibly
rare, you're worrying about nothing.

In any case, as has already been pointed out by more than one person,
simply removing it from the Standard is certainly /not/ going to
"suddenly break" all the existing legacy code.

The changes from C90 to C99 were /far/ more likely to break migrated
code than the removal of gets() would be.

 

[ptk]

This code will do what you want...

#include <stdio.h>

int main(void)
{
char stringInput;

do
{
printf("\nWrite to result.txt (y/n)? ");
stringInput = getchar();
__fpurge(stdin); // clear the stdin to strip off the previous newline char.

???__ fpurge? What page of the standard is that on?
[snip]

man fpurge

I think he meant fpurge not __fpurge. At any rate, fpurge is in stdio

 

[Jordan Abel]

This code will do what you want...

#include <stdio.h>

int main(void)
{
char stringInput;

do
{
printf("\nWrite to result.txt (y/n)? ");
stringInput = getchar();
__fpurge(stdin); // clear the stdin to strip off the previous newline char.

???__ fpurge? What page of the standard is that on?
[snip]

man fpurge

I think he meant fpurge not __fpurge. At any rate, fpurge is in stdio

but not in standard c.

 

[Rod Pemberton]

I don't believe that there are a significant number of programs that
use gets() safely. I believe there are a plethora of programs that
use it unsafely. Leaving Jordan's suggestions aside, simply removing
gets() from the standard would not break a single one of them.

Why stop with gets()? Why don't you just list all features of C you think
are

1) unsafe
2) useless
3) unstructured
4) lacking sufficient bits, etc...

Mentally remove the features from C, and ask yourself this: "Have I
recreated Java? Or worse, Pascal?"


Rod Pemberton

 

[Flash Gordon]

Why stop with gets()? Why don't you just list all features of C you think
are

1) unsafe
2) useless
3) unstructured
4) lacking sufficient bits, etc...

The reason has already been stated in this thread by more than one
person. gets is the only function that it is *impossible* to use safely
without a lot of things completely outside of the standard, and even if
you go outside the standard it is still exceedingly hard to make the use
of gets safe.

Mentally remove the features from C, and ask yourself this: "Have I
recreated Java? Or worse, Pascal?"

Get rid of uncontrolled level crossings on blind bends and you still
have a railway and road system, but you no longer have a feature that is
impossible to use safely.

There are other features of the language you would have to work hard to
convince me to use, but I'm not arguing for there removal.
--
Flash Gordon
Living in interesting times.
Web site - http://home.flash-gordon.me.uk/
comp.lang.c posting guidlines and intro -
http://clc-wiki.net/wiki/Intro_to_clc

 

[Flash Gordon]

This code will do what you want...

#include <stdio.h>

int main(void)
{
char stringInput;

do
{
printf("\nWrite to result.txt (y/n)? ");
stringInput = getchar();
__fpurge(stdin); // clear the stdin to strip off the previous
newline char.

???__ fpurge? What page of the standard is that on?
[snip]

man fpurge

I think he meant fpurge not __fpurge. At any rate, fpurge is in stdio

Whichever he meant it is not in stdio.h on my system, and nor is it part
of the language. It may be an extension available on your system but
that is a different matter. Here we only deal with standard C.
--
Flash Gordon
Living in interesting times.
Web site - http://home.flash-gordon.me.uk/
comp.lang.c posting guidlines and intro -
http://clc-wiki.net/wiki/Intro_to_clc