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

[kuyper]

Rod Pemberton wrote:
....

Why stop with gets()?

a) We shouldn't stop with gets(), In the long run, every feature of the
C standard that can be improved while staying within the spirit of C
should be improved, sooner or later. All that we're saying is that
removal of gets() should have been high on the list of features to be
removed from C, even way back when it was first standardized. The fact
that the standard has gone through several amendments and one full
revision since then, and gets() is still not even deprecated, is quite
hard to understand.

b) The reason why gets() should be high on the list has been repeatedly
pointed out in this thread. It is unique among all of the other
problematic features of C, in that there is essentially NO safe way to
use it (Doug's assertions to the contrary notwithstanding), and there
has always been a safer alternative.

 

[Joe Wright]

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

It is in my DJGPP setup but nonetheless..

Syntax
------

#include <stdio.h>

int fpurge(FILE *file);

Description
-----------

If FILE designates a buffered stream open for writing or for both
reading and writing, this function purges the stream's buffer without
writing it to disk. Otherwise, it does nothing (so it has no effect on
read-only streams such as `stdin').

Return Value

 

[Keith Thompson]

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?"

You really haven't been paying attention, have you?

I'm stopping with gets() because gets() is uniquely dangerous.
The reasons have been explained many times.

 

[Rod Pemberton]

You really haven't been paying attention, have you?

I'm stopping with gets() because gets() is uniquely dangerous.
The reasons have been explained many times.

It's also a low use function that noone really cares about and is rarely
used. People who do care about it use safer functions. And, I think you
missed the point of my statement. If you can correct problems with C, why
not just fix all of them? It's hard to believe that you think gets() is the
absolute worst feature or problem with C. But, for a guy who heavily argued
over a single bit difference with P.J. Plauger, I guess it might be the most
important thing to you.


Rod Pemberton

 

[Flash Gordon]

news:[email protected]... [...]
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?"

You really haven't been paying attention, have you?

I'm stopping with gets() because gets() is uniquely dangerous.
The reasons have been explained many times.

It's also a low use function that noone really cares about and is rarely
used.

The problem is it *is* *still* *used*. Just search this group for all
the times people use gets.

> People who do care about it use safer functions.

If it didn't exist, no one would use it.

> And, I think you
missed the point of my statement. If you can correct problems with C, why
not just fix all of them?

Because most of the other dangerous features (or problems) have at least
some redeeming points, sometimes the redeeming point being that it
allows you to write your low level HW access routines in what is
basically C with one or two system specific assumptions (i.e. converting
0x1234 to a pointer will give you a pointer to some HW register you need
to access).

> It's hard to believe that you think gets() is the
absolute worst feature or problem with C.

It's easy to believe, since it is the only feature that fundamentally
*cannot* be used safely.

> But, for a guy who heavily argued
over a single bit difference with P.J. Plauger, I guess it might be the most
important thing to you.

I'm sure there are far more important things to Keith, just as there are
to me. For example, whether my new notebook arrives next week as
promised is far more important to me.

 

[Chris Torek]

[The fpurge() function] is in my DJGPP setup but nonetheless.. [... snippage]
If FILE designates a buffered stream open for writing or for both
reading and writing, this function purges the stream's buffer without
writing it to disk. Otherwise, it does nothing (so it has no effect on
read-only streams such as `stdin'). [...]
Portability

And not compatible with the 4.4BSD fpurge() (which I wrote):

The function fpurge() erases any input or output buffered in the given
stream. For output streams this discards any unwritten output. For input
streams this discards any input read from the underlying object but not
yet obtained via getc(3); this includes any text pushed back via ungetc.

Hence, there are multiple functions with the same or similar names
that do different things. This is one of several risks you take
if you choose to use non-Standard functions.

 

[CBFalconer]

[The fpurge() function] is in my DJGPP setup but nonetheless.. [... snippage]
If FILE designates a buffered stream open for writing or for
both reading and writing, this function purges the stream's
buffer without writing it to disk. Otherwise, it does nothing
(so it has no effect on read-only streams such as `stdin'). [...]
Portability

And not compatible with the 4.4BSD fpurge() (which I wrote):

The function fpurge() erases any input or output buffered in the
given stream. For output streams this discards any unwritten
output. For input streams this discards any input read from the
underlying object but not yet obtained via getc(3); this
includes any text pushed back via ungetc.

Hence, there are multiple functions with the same or similar names
that do different things. This is one of several risks you take
if you choose to use non-Standard functions.

Your version seems eminently useful, and offhand I see no reason
for it not to be implementable on all C systems. Not portably
implementable, however. Which, to me, is an excellent reason to
incorporate it in the standard.

It might return EOF if at EOF, 0 for success, positive for error.
Maybe it does.

--
"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/>
Also see <http://www.safalra.com/special/googlegroupsreply/>

 

[Richard G. Riley]

I don't understand your point here. If gets() is removed from the
standard, it can still be provided by the library. If gets() is

End of subject there. I was under the impression that pitchfork and
torch crowd wanted it removed completely. So no real argument from me.

removed from the library, an exactly equivalent function with the same
name would be trivial to write. This replacement would be exactly as
useful, and exactly as dangerous, as the current standard gets().

If replacing all calls to gets() by calls to a safer alternative is
too much effort, *you don't have to do it*.

[snip]

Please be sure that I am in no way condoning gets() as a function to
use : rather I am advising caution on the decision to remove
it.

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

Assuming as it is still there , then no.

 

[Richard Bos]

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

Sure. But this involves bondage gear, a single-user computer that has
never been connected to any kind of network, and deleting the executable
immediately after the single run. Even then, you'd better not slip while
entering your allotted 128 - oops, 127 - characters.

Richard

 

[Richard Bos]

Who's being condescending?

Someone who dismisses an opinion held by many people for years as
"trendy".

I was one of the people who
captured and analyzed the Morris worm at the time. I've
been involved with information security for more than
30 years.

Then you should know better than to continue to support one of its entry
holes.

Perhaps you should try to understand my point rather than rejecting it a priori.

Perhaps you should not dismiss an opinion I've held for years now as "a
priori".

Richard

 

[Dave Thompson]

If anyone thinks removing implicit int was a good thing because it adds
a requirement for using a function without a declaration in scope, there

Surely you don't mean 'requirement for'. Either requirement against,
or diagnostic for.

was a more direct way the same result could have been achieved. Adding a
requirement that there be a declaration in scope.

s/could have been/was/


- David.Thompson1 at worldnet.att.net

 

[Douglas A. Gwyn]

Prior to the ANSI standard, strdup() was commonly part of the C
library, right?

Why did the C89 standard include gets() but not strdup()?

Because gets() was in the legacy library and strdup() wasn't.

Some of us tried to get strdup() adopted for the standard,
but there was resistance primarily on the grounds that no other
standard function malloc()ed storage and the opposition didn't
want to start that as a design trend.

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?

Actually I argued against including it in the first place,
but now that it is part of the standardized interface I see
no benefit and some harm in its removal.

 

[Jordan Abel]

Because gets() was in the legacy library and strdup() wasn't.

Some of us tried to get strdup() adopted for the standard,
but there was resistance primarily on the grounds that no other
standard function malloc()ed storage and the opposition didn't
want to start that as a design trend.


Actually I argued against including it in the first place,
but now that it is part of the standardized interface I see
no benefit and some harm in its removal.

what harm?

 

[John Devereux]

Some of us tried to get strdup() adopted for the standard,
but there was resistance primarily on the grounds that no other
standard function malloc()ed storage and the opposition didn't
want to start that as a design trend.

Is it really true that no standard function malloc(s) storage?

 

[Douglas A. Gwyn]

Sure. But this involves bondage gear, a single-user computer that has
never been connected to any kind of network, and deleting the executable
immediately after the single run.

Hardly. Gets() has been used in a zillion contexts where it has
not overflowed the allotted buffer, so it must not require all
of what you describe. You probably have in mind a usage model
that does *not* include controlling the input to stdin, which is
a different context.

 

[Douglas A. Gwyn]

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

First, you cannot "remove it tomorrow"; it's currently required
for standards conformance, and gets() will continue to be provided
in standard libraries for the indefinite future, even if it
eventually is no longer allowed for conformance for it to be
declared in <stdio.h> (which is a change that much legacy gets()-
using code wouldn't notice, due to explicitly declaring gets()
directly).

Also, if those books (taking your word for it since I'm not
familiar with them) use gets(), they should use the opportunity
to teach about the general buffer overrun issue, which is easy
for a novice to run afoul of. Indeed, a function similar to
gets() could easily be dreamed up as a nice way to encapsulate
reading a text line, and if the issue is not appreciated the odds
are that the programmer will just recreate the same problem.

Finally, if those books are claiming that gets() is good practice
for general contexts (unconstrained stdin), then they already
have no good defense; the "defense" that the interface can be
found in some (non-safety oriented) standards document is already
not justification for using any function inappropriately.

Pedagogically, gets() is a good example to have around.

 

[Douglas A. Gwyn]

... People who do care about it use safer functions.

Indeed, and they generally use their own support library.
The converse point is important also: Please who don't
exert sufficient care about gets() usage aren't likely
to produce safe code regardless of whether gets() exists.

 

[Douglas A. Gwyn]

Your version seems eminently useful, and offhand I see no reason
for it not to be implementable on all C systems. Not portably
implementable, however. Which, to me, is an excellent reason to
incorporate it in the standard.

It's not evident how useful it is in general, because details
of the buffering vary among platforms. For example, on some
systems multiple input or output lines might be buffered while
on others just one line at a time might be, depending on file
type etc. There are also multiple levels of buffering,
including kernel character queues, etc. and one needs to
specify whether or not unread/unwritten buffered data is
flushed at that level also. For a specific platform one can
handle all the details, but for general use it would be not
only a problem to specify adequately but also to use in a
portable manner.

 

[Keith Thompson]

Is it really true that no standard function malloc(s) storage?

Well, obviously malloc() does, and calloc() and realloc() effectively
do. Other than that, fopen() and other functions *could* malloc
storage behind the scenes, but not in any manner that's visible to a
calling program.

 

[Jordan Abel]

Hardly. Gets() has been used in a zillion contexts where it has
not overflowed the allotted buffer, so it must not require all
of what you describe. You probably have in mind a usage model
that does *not* include controlling the input to stdin, which is
a different context.

And how is the input controlled? Blind luck?