On Aug 10, 6:25*pm, Antoninus Twink <nos...@nospam. invalidwrote:
a_03.c:(.text+0 x4d): warning: the `gets' function is dangerous
and should [never] be used.
...
Of course, this is nonsense. There is a perfectly safe way to use
gets(), namely by being in control of what appears on stdin.
Heresy! I'm surprised no one launched a diatribe here
against Mr. Twink, so let me offer a diatribe in support!
Six comments on gets().
First, some history. (Some c.l.c'ers weren't
even alive at the time of the infamous Internet
Worm.)
The infamous worm was complex enough to attempt
exploitation of at least 4 different security loopholes,
but just one of the loopholes was ubiquitous enough
to make it necessary and sufficient for the Worm's
"success." That loophole was the dangerous use
of gets() in a program (fingerd) usually run with
superuser authority. It was the exploits of the
Internet Worm that led to the deprecations against
gets(). (The exploiter, IIRC, wasn't a larcenous
"black hat", but rather a "gray hat" who deliberately
aroused the Unix community from its apathy about
such bugs.)
The fingerd->gets() exploit was not trivial.
The overrun buffer was an automatic variable just
below a procedure frame, whose return-address was
modified to point to executable code within the overrun
buffer. That code loaded and ran another program
(misnamed 'sh' or 'csh') which, among other things,
executed the 'fake finger' program to exploit the
fingerd->gets() bug on still other machines.
The detailed steps of this exploit get elided in the
retelling, and programmers are left with the take-home
lesson: use gets() and the Russian mob will take
over your machine and the rest of the world.
One doesn't have to be a gets() enthusiast to note
fingerd's special nature, and that the claim that
all gets() usage risks catastrophe is confused.
Second, a confession.
Whenever I build the Index to the Fabulous Pedigree
http://fabpedigree.com/altix.htm
I do several hundred thousand gets()'s, but none of
them are "dangerous" . I live with a few "dangerous"
messages during the build (although I'm sure the pedants
would prefer that each of the several hundred thousand
gets()'s produced its own such message. :-)
Perhaps there's a way to disable gcc's "dangerous"
message but, in keeping with the FSF philosophy, I'm
sure the cure is worse than the disease, something like
setenv IM_AN_UNREPENTA NT_MORONIC_ASSH OLE
Third, a boast:
Since another of my "eccentric" codings, in private
throw-away code, is to *not* test malloc()'s return for
zero (failure leads to a core dump, which is what I want
anyway(*)), I'm sure that many in this ng believe that
James Dow Allen's code is buggy! I do not believe
this is the case. When I was rehired after a year to
add new support to a complete OS I wrote as a contractor
I was pleased to note that no changes had been found
necessary to my delivered code. Code reliability
doesn't require ingenuity (indeed the two may be
inversely related!); it requires conscientiousne ss
and avoiding the cheap substitution of dogma for thought.
AFAIK, I've never used gets() in code I've delivered
to a customer. (This is partly because most of my delivered
code has been OS or standalone, with any stdio library
calls unavailable.) I do use gets() sometimes, on
private code, when the gets()'ed string was itself
machine-produced. The gets() buffer is usually at least
ten times as large as the longest machine-produced
string. The executables are protected from the
Internet by an Impenetrable Firewall. If someone does
break into my house, intending computer mischief,
I'd be surprised if his mischief needed to invoke gets().
The gets() deprecators aren't wrong; indeed I'll cheerfully
concede that their position is more defensible than mine!
But I'm happy to take a Devil's Advocate position to
encourage critical thinking when I see the preposterous and
dogmatic over-generalizations which become so routine in
this ng. Is gets() a *potential* source of bugs? Obviously.
But I'd love to organize a wager, between me and one of
the pedants, on whose code contains more *actual* bugs.
* - Detractors will argue that what I *should* want to
do is spend hours writing a diagnostic for such malloc()
failures! In fact I don't want to do anything about them
since the smallish malloc()'s I use to build the website
Aren't Going To Fail(tm). (The pedants will respond to
this with some nonsense about how the website building
may be ported, some day, to the limited-memory chip
inside my car's fuel injection system !)
Fourth, a peeve:
fgets() preserves LineFeeds, gets() discards them.
Either behavior is fine (an application whose
stringency requires special treatment of an
"unterminat ed last line" probably will avoid
fgets() for other reasons anyway), but similarly-named
functions *SHOULD BEHAVE SIMILARLY*.
Assuming gets() came first and it was too late to
redefine it, fgets() should have either handled LineFeeds
the same, or have been given an obviously different name.
Whoever created the disparity in these similarly-named
functions should have done to him what Jesse J. secretly
claimed to want to do to Obama.
I *might* have changed from gets() to fgets() on some
of my private code if it weren't for the above nit.
(And yes, I *do* know how to do
if (*s == '\n') *s = 0;
in C.)
Fifth, an oft-overlooked truism:
Programming (and much real-world activity) involves
compromise between thoroughness and convenience.
strncpy(), for example, can do everything(*) strcpy()
can do, *except*, when properly coded, overrun a buffer.
In other words, the *only* reason to ever use strcpy()
(besides deliberately creating a security loophole!)
is the convenience of a 2-argument function call compared
with a 3-argument call. (* -- yes, strcpy() doesn't
null-pad. Any c.l.c'er ever write code that relied
on the *non*-padding?)
Thoroughness is not wrong, *BUT YOU SHOULD SPEND YOUR
THOROUGHNESS WISELY*. The original Hubbell Telescope
program spent $10,000 studying whether or not to do a
$3 Million test. Meanwhile the flaw, that showed up
post-launch, could have been found with a simple $50 test.
I'll bet some engineer would have done the $50 test
if not dizzied by the testing paperwork requirements
dictated by pedants.
Finally, let's note that programming and lawyerism
are different crafts.
The Authorities(tm) who post so pedantically in this
ng are often not completely wrong, but their pretentious
comments about gets() show confused thinking. In
particular, I wonder if some of them are law school
dropouts.
When I mention the gets()'s that I use, in private,
behind my Impenetrable Firewall(tm), on strings generated
by my own Bugfree Software(tm), they never acknowledge
that some gets()'s are less dangerous than others
but instead reject "safe" usages of gets() based on
pipe(fd);
dup2(fd[0], 0);
write(fd[1], "Hello world\n", 13);
printf("%s\n", gets(buff));
on grounds that the semantics of pipe(), etc. are *not
guaranteed* by the C Standard(tm).
If anyone has trouble understanding the absurdity and
hypocrisy of this legalistic view, I refer them to answers
previously given, here in the ng.
Hope this helps, :-)
James Hussein Allen
