Chuck wrote:
They're all dangerous. For example, a one bit error
in reading a '\n' from your prewritten data can
blow everything.
I won't address Mr. Falconer's charges in the sequel,
but I *do* refer to the problem he cites, so I quote
him here lest someone accuse *me* of ingesting
the wrong kind of mushrooms.
Chuck doesn't specify what causes such byte damage.
The Russian mob? The Pentium Bug(tm)? gets() itself,
due to Trojan House sabotage by the Deprecator-in-Chief?
I'll (give Chuck the benefit of the doubt and) assume
the problem is gamma radiation.
On Aug 13, 7:44 am, Paul Hsieh wrote:
On Aug 11, 1:38 am, James Dow Allen <jd*********@yahoo.comwrote:
The fingerd->gets() exploit was not trivial.
Well by today's standards it is. ...
I know exactly how this is done and why and how it works.
Even *I* could and did write a 'fake finger' from the brief
description. In 1988 the message logs of those I knew got
the message:
You have been finger-f*cked by root
When the quick workaround (chown/chmod) was done, the message
became the slightly more mysterious (and Odyssean?)
You have been finger-f*cked by nobody
>[...] 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.
Uh ... the Russian mob *does* use hackers ...
Uh ... yes. But watch the conclusion you're about to reach
and see if blind dogma is subverting rational thought.
>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.
fingerd's special nature is that it used an auto buffer
to accept input and it used gets()....
No. fingerd's special nature was that stdin was directed
to a socket connected to an (untrusted) external machine.
Obviously gets()'er's in that environment deserve to have
their n*ts c** *ff. No one has implied anything different.
You managed to write several paragraphs on this subtopic
without even hinting that you understand that the gets()'s
we're "defending" are simply not subject to Russian mob
exploitations!
>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 I\'M_AN_UNREPENTANT_MORONIC_ASSHOLE
In what sense is removing this message worth it? Why not
just call fgets() and nail the trailing \n?
I've time to read very few Usenet groups these days.
Are many as totally devoid of humor as c.l.c?
Did anyone seriously think I was worried about the warning
message? (I *do* use a simple 'grep -v' to remove
one irrelevant gcc warning, but haven't bothered for
the friendly "dangerous" message.)
(Even in rec.puzzles, when I said I'd omitted a
smiley-face to "save bandwidth" I received an
overly-sober response about modern modem speeds!
You're the guys who like to over-generalize, but
I'm tempted to guess that if Americans had a better
sense of humor some of the recent domestic and
geopolitical crises might have been avoided.)
Another poster implied that a reason gets() is "dangerous"
is that it will disappear when the pedants take over
libc! Does anyone think any of us would have trouble
writing our own gets() when it goes missing from libc?
(This would also be a trivial way to get rid of the
"dangerous" message.) In fact, at the risk of encouraging
the mob to Repeat_The_Obvious One_More_Time I'll put a
gets implementation in the public domain right now:
/* Not tested :-) */
char *gets(char *s)
{
s = fgets(s, 1000000, stdin);
/* core-dump immediately if a cosmic ray has
* damaged the terminating LineFeed:
*/ if (s) 0[index(s, '\n')] = 0;
return s;
}
Hmmm. Surprised that the pedants don't add a string length
count to index() to deal with unterminated strings.
:-) :-) :-) :-)
I have looked at your code (on your website).
Buggy is not the right word for it.
*Narrow* is more what I would use.
"Narrow" is unclear. I'll assume you meant something
worse, but are being polite! In any event *most* of
the example programs at my website are just that:
*examples* rather than library functions intended for
immediate reuse.
I think there may be some useful ideas at my site.
For example, real-time programmers might benefit from a
glance at
http://james.fabpedigree.com/lesson9.htm#p94
but I imagine if you condescend to comment further
it will be to nitpick or to gloat when you find some
fragment still written in old-fashioned K&R C.
Recently I added functions to operate on compressed
sparse bit strings:
http://james.fabpedigree.com/sofa.c
which *is* intended as a small but useful (for some)
downloadable package. Paul (and anyone else) is welcome
to examine it and offer comments.
... like your hash table. Your program can only ever
support one of them, so its flaw is more fundamental.
I guess I've not uploaded my cuckoo hash implementation
yet, so you're referring to the hash table I introduced some
years ago under a Subject like "Reusable Source code".
To say that program "can only ever support one [hash table]"
is to ignore that its source code can be modified!
It's My Own(tm) code for My Own(tm) projects; I use
Just-In-Time Programming(tm) for My Own(tm) projects,
and have found this code easy to modify. As it turns
out, not supporting the feature you mention was the correct
Just-In-Time Programming(tm) decision, as that routine has
been superseded by my cuckoo hash implementation which
*does* support multiple users.
The "Reusable Source code" thread used the hash table source as
an example of a concept, without necessarily espousing *that
particular* source code. The point of the thread wasn't hash
tables, it was "Reusable Source Code" in the sense that
% vi hashtable.h
% $CC -c hashtable.c
% $CC application.c hashtable.o
allows more flexibility than the simple
% $CC application.c hashtable.o
As a specific example of the need for customization
(of hash table handling) I mentioned that many applications
permit a *maximum* of two bytes per entry (because essentially
all available memory must be well exploited) while most
off-the-shelf hash table handlers require a *minimum* of
eight bytes per entry for overhead! (Many of us use hash
tables for combinatorial searches or memory-efficient
graphs; these use smallish fixed-length keys, rather than
the variable-length keys usually assumed by hashlib, etc.)
But the whole point was completely lost, as Chuck reacted
defensively re his own hashlib (without ever explaining how
the user needing two bytes maximum could cope with hashlib's
eight-byte minimum), and Paul enlightened us with code in
which Paul (or his dog?) proudly allows the programmer to
replace the confusing, error-prone predicate
(! p->curr)
with an invocation of the function
int utilGenLinkedListIteratorEndReached \
(struct genLinkedListIterator * iter) {
if (iter == NULL) return -__LINE__;
return NULL == iter->curr;
}
Is this the kind of code you think I need to improve
my pedigree generator, Paul? Maybe I should train
*my* dog to come up with useful gems like
int add_two_numbers(int number1, int number2) {
return number1 + number2;
}
int add_three_numbers(int number1, int number2, \
int number3) {
return number1 + add_two_numbers(number2, number3);
}
or perhaps a better caricature of Pedantic Programming(tm)
might be:
int divide_checking_for_zero(int a, int b) {
if (b != 0)
return a / b;
else /* illegal: send an appropriate signal: */
return a / 0;
}
:-) :-)
>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....
Can I obtain your OS and run the
Firefox browser on top of it?
Hunh? The OS performed to customer spec, which was
to do a MS-DOS lookalike on MC68000 chip. I estimated
how long it would take me (quite accurately as it turned
out), multiplied by my then-generous hourly wage and
ended up underbidding a company which probably already
had the OS on-shelf and was charging just for hand-holding.
My customer (who got exclusive rights -- I never claimed
to be a businessman) ended up selling the source to
A Very Big Company You've All Heard Of(tm) and recovering
his payment to me. (The Company's representative spent
several days on-site at my customer's examining the source
"eyes only" and concluded with a comment: "Originally I
was almost sure we'd develop our own in-house instead,
but after examining the source ... Sold!")
>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.
I'm sure you could peg me as the worst of the gets "pedants" ...
... I honestly take the position that gets() should, as a
side effect, attempt to delete the source file that
contained it the moment it is run.
With your "honestly", one is tempted to guess you might
not even be joking! If so: Wow! Words fail me.
Earlier I wrote:
>The gets() deprecators aren't wrong; indeed I'll cheerfully
concede that their position is more defensible than mine!
I'm afraid I'll have to (cheerfully) retract that concession
in your case, Paul.
As I compose this reply, I'm reading, in another window, about
present-day Internet security problems, despite the Billion$
of $$$ spent on $oftware by Micro$oft and others. Frankly,
I doubt that the problem is programmers using simple
functions to do simple things, but is more likely to be
the overly complex methods some of you seem to advocate.
For example, your whole "family tree" project ...
My Family Tree project started out when I wanted to
print our pedigree and snail-mail it to my nieces, but found
that 2 or 3 pages wouldn't be enough. After that
it ... er ... gradually got out of hand ... :-)
I confess that code would look *quite* different if
starting over or delivering it to a paying customer.
Just now I did
grep "gets(" *.c
in the tree subdirectory and was slightly surprised at how very
few there were. (The estimate of several 100,000's of gets()
*executions* was still conservative as the Index starts with
330,000 lines which are passed pipe-like to three
gets()'ing filters.)
... you did the whole thing in C didn't you?
Call it a fetish if you wish, but I *do* like to program in C.
My brain isn't completely dormant here, raising my kids and
smelling the roses: I read up on a variety of topics, e.g.
historical linguistics. Learning a new programming language
is *not* a priority and wasn't even before I retired, unless
you count LaTeX as a "programming" language.
And you chose C because ...
you think its actually tighter or something;
even though you are using
massively over-sized buffers to hold those strings.
LOL, chuckle! Call me simplistic but I process one line
at a time. The PC I use has relatively little memory,
but it's enough to spare one (1) 2000-byte buffer
for one (1) 200-byte string. :-) :-)
Moreover, your comments show another confusion: one uses
the "over-sized buffer" whether one gets()'s or fgets()'s.
In either case, if the string needs to be preserved,
one strlen()'s, malloc()'s, and strcpy()'s (*) Yes, one can
hire Chuck F. to implement this trivial functionality, but
so what? (* - or do the pedants use strncpy() instead of
strcpy() even when they've just strlen()'ed on the off-chance
a gamma-ray zapped the null terminator? :-)
True, the fgets() *can* handle lines too long to fit in
the already "over-sized" buffer, but if you're doing that
handling in more than 2% of your fgets() applications you must
be coding like a masochist! The whole point of gets()/fgets()
is the simplicity of reading exactly one line: if you lose
that, you might as well just use fread().
deal with the growing list of tree nodes? Do you painstakingly
allocate each one, then free them all?
... Even if you do it in C, you are going to
want to write a special tree node allocation pool layer
and use a string library.
You seem to have a model of what my software does which
has very little relationship to its reality. There certainly
are painful parts, but they have nothing to do with growing,
allocating, or freeing. Programming speed and reliability
depend on simplicity and you are imagining problems I've
never encountered in 'tree.'
Of course you do, you revere K&R as if they were gods.
If you've been reading my website, you're misquoting!
I revere T&R (not K&R) as if they were human, but excellent
and creative designers.
>Programming (and much real-world activity) involves
compromise between thoroughness and convenience.
Giving up on thoroughness is basically never worth it.
>Thoroughness is not wrong, *BUT YOU SHOULD SPEND YOUR
THOROUGHNESS WISELY*. The original Hubble 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.
That's the wrong lesson. The right lesson: the only way to catch
everything via a test, is to test everything....
I'm agnostic about whether the taxpayers should have been
required to fund the expensive test; the point is that the
flaw would have surfaced readily (with the $50 test) in a
less pedantic testing environment. You seem to have missed
this point; indeed you seem to be arguing that *no* test is
too expensive for the taxpayers! ... Where do you fit on the
political spectrum, Paul? :-)
Regarding my claim, which you contested, that one
SHOULD SPEND ONE'S THOROUGHNESS WISELY
consider again the table hander you deprecated as
single instance. Making it multi-instance *would* have
complicated it and did indeed prove unnecessary.
I once worked with a guy who added so many unnecessary
features to his software package, that it was difficult,
later, to add *useful* features he'd overlooked.
I think
SPEND ONE'S THOROUGHNESS WISELY
is a good synopsis of this whole subthread.
There's a lot of changes I'd make to the 'tree'
software if it were worth my while spending time cleaning
it up. Replacing gets() with fgets() is *definitely*
not on the list.
OP wrote, to start the thread:
Is linux more dangerous than windows?
*This* is a joke, right?
a_03.c:(.text+0x4d): warning: the `gets' function is dangerous
and should not be used.
Please advise my instructor says gcc is overly pedantic.
Good question! Thanks for asking. :-)
James Hussein Allen
