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

[Jordan Abel]

Oh, did someone say that there was a requirement not to teach obvious
stuff? Hmm, that must have escaped most of the establishment.

There's still the fact that everyone learns it, while no non-programmer
is told about buffer overflows and even users of your program who are
competent in programming won't know that your program contains a buffer
overflow flaw unless they actually look.

 

[Joe Wright]

Probably, "no standard function shall call {c,m,re}alloc or free".
OTOH fopen, fclose, setvbuf, and some others may dynamically
(de-)allocate memory.

Do you mean to be confusing?

 

[Randy Howard]

Douglas A. Gwyn wrote

New code doesn't need to use gets.

But it does. At a scary rate. It is apparent that far too many
of those learning C today are being taught by dinosaurs.
Perhaps a surprise inspection of C instructors world-wide needs
to be held next Tuesday, and anyone that isn't familiar with the
gets() problems would be killed on site. But, I digress...

Recall that gets was
specified in the standard simply because it was a widely
used piece of the base library. Almost any function can
be abused, but that doesn't mean they all need to be
deprecated.

But gets() does. Not only can it be abused, it's almost
impossible to use it in a way that isn't problematic.

Perhaps the reference implementation of gets() -- if for some
unfathomable reason it is not deprecated -- should be the normal
broken, crap behavior, along with the added bonus of a message
output to stderr (if available) along the lines of:

** WARNING: The programmer that wrote this code is lazy,
** poorly trained, and in dire need of a 2x4 up the side of the
** head. If you continue to use this program, despite this
** issue, you need to have your head examined as well.
** Suitable replacement candidates can be recruited from
** comp.lang.c or comp.std.c. Now back to your broken program
** in progress...

 

[Randy Howard]

Richard G. Riley wrote

I was referring more to the fact its buggy in a reentrant system
since its internal databuffer is static.

That's not a bug, it's a failure of the programmer to understand
what he/she is doing. Lots of functions are not reentrant.
That does not mean they are buggy. You could make a case for a
warning in the man pages or other documentation for the
terminally thick, but that's a different issue.

But anyway, regardless, why the pressure on the other function
[ed: gets()] which is undoubtedly in hundreds of thousands of
lines of legacy code?

Because it is in hundreds of thousands of lines of legacy code.

Seriously.

If you don't understand the problems with gets() at this point,
you are in dire need of a clue. Google for gets buffer overrun
and start reading.

 

[Bart van Ingen Schenau]

No. How is an automobile's direction controlled? By blind luck?

I would say that using gets() for input can better be compared to using
an accelerometer that has too small a range to detect a crash at 120
km/h. "Warning: At speeds exceeding 60 km/h, the airbags may fail."

Bart v Ingen Schenau

 

[those who know me have no need of my name]

in comp.lang.c i read:

But that is precisely the point. Only the system designer knows
how to make the function work on his system. I should think of it
as a means to guarantee that any future input occured after the
call to fpurge. It puts the input system in a known state and
avoids having to keep track of line ending absorption.

perhaps. it certainly would make some people think that such a state could
be reached, when in fact there are aspects that can never be covered. time
is a harsh mistress -- consider bytes still in flight and thus, perhaps,
partially received sequences.