No, he's not saying that an argument is wrong because Mr Nilges is
making it. He's saying that Mr Nilges's support for an argument is of no
value in determining whether or not the argument is valid. That's very
different.
Here is an example of "ad hominem" argument:
"Mr X says strcpy is dangerous. Mr X doesn't know spit about C.
Therefore strcpy is not dangerous". Poor reasoning.
Here is an example of what Seebs is saying, using the above
(hypothetical) case:
"Mr X says strcpy is dangerous. Mr X doesn't know spit about C.
Therefore X's claim that strcpy is dangerous adds no value to the
argument that strcpy is dangerous. Whether it is or isn't dangerous is
another matter entirely."
The fallacy here is that while I know a bit about C, I know in fact
less than the regulars: but the regulars are uneducated in computer
science and who are incompetent programmers (who know a lot of rote
facts about C):
* Peter Seebach has by his own admission never taken a computer
science class, and in consequence makes silly off by one bugs, thinks
designing a common data structure (a circular linked list) is
practically a termination offense, and at least at the time of his
Schildt attack, thought that "the 'heap' is a DOS term"
* Richard Heathfield "engineers" a "reusable" linked list by
physically copying node values into nodes instead of using pointers,
creating a "reusable solution" that is O(M*N), prone to unpredictable
failure in production.
Managers who don't know how to manage free men and women prefer that
headhunters find men and women who are overly specifically "trained"
in platforms, and the result is plain.
That is, he is in effect claiming that it is possible that even someone
who knows little about a subject may know enough about it to make a
correct claim, or may simply make a correct claim by chance. So, moving
back from the abstract to the concrete, he is not dismissing any claim
made by Mr Nilges as being necessarily incorrect. That would be foolish,
not only because it would be an invalid "ad hominem" argument, but also
because Mr Nilges (who is on record as saying that he wishes to cause
maximum damage to this newsgroup) could exploit such a position by
deliberately making claims that are clearly true.
I don't know where you or Julienne get that claim you said I made:
that I wish to destroy this newsgroup. It sounds like the way Arabs
and Iranians, speaking in writing in their own language are
systematically mistranslated (by Israeli translation firms) as saying
"death to Jews" when for the most part they are calling for an end to
the criminal gang that has put the Jews of Israel at risk with their
criminal policies.
In fact, I always am the source, according to all neutral observers,
of interesting content.
Taking your specific points one at a time:
Whilst it is true that strcpy offers no added protection against buffer
overrun, careful programming overcomes this problem. Thus, strcpy does
not get in the way of the programmer who knows full well that his buffer
is sufficiently large - no performance penalty is imposed.
Knowledge is justified true belief, and programmers who decide that
some power of two is "big enough" don't usually verify this with end
users. Furthermore, knowledge is justified true belief, and most end
users don't know the answer either. Therefore, the best policy is to
use an approach in which you don't have to worry about "buffer
overrun", and this is easy in using a modern language such as C Sharp
or Java. In C, it's easy if one has taken a computer science class in
data structures, and had the chance in a true university to create a
linked list without some moron of a manager asking what you're doing.
With the linked list, you still have to worry about malloc failing.
But if you're competent, you call malloc checking its return. Whereas
allocating a buffer that you "think" is "big enough" and then blindly
copying to it is asking for trouble.
Sure, if you're reasonably competent, you will check the current size
of the string in the buffer against the allocated maximum (and, if
you're reasonably incompetent, you will do so with what even you, dear
Richard, knows is an O(n) strlen call, hopefully not using Peter's
famous off by one version). If you are a little more competent you
might even #define a symbol with the maximum rather than hard coding
it in two places.
But this of course doesn't begin to address the fact that in the so-
called "real world" (referring to it as reality, not in mythical
incantatory invocation), the buffer size will under maintenance
eventually become, for trivial jobs, always the maximum amount it
needed to be for unusual jobs, making for a performance pig.
Yes, strcat and strlen are O(N) - so, where it matters, you remember the
string length, having found it out the first time. These two functions
offer simple solutions to a simple task, and as such are very often a
"Simple" to the Simpleton is always a term of Praise:
It means "at last I understand it, to my inner shame'd amaze":
He then imposes this lack of Art upon the sage and Wise
Whenever in Authority, to their shock, and awe'd surprise.
Beggars ride fine horses, whipping them in scorn:
Shouting, we must understand, tho' their comprehension be porn:
Belisarius puts his Foot upon the scholar and the priest,
Commanding them on pain of death to say to him the least:
Yet Vandal, Goth, Visigoth, Ostrogoth and Byzantine:
Need the wisdom of the learned to find the gold they'd glean:
So they can fill themselves with swill and ravish the name of Art
Expelling all at fair Rome's fall in one almighty Fart.
good solution to the task at hand. Where that is not the case, we have
the option of building more powerful tools.
Actually, we don't, since the ability is extinguished by Envy and
Rage:
When Barbarians are in control, the cry is death unto the sage.
(And yes, I agree that
strcat's interface could be improved; for example, it could return a
pointer to the null terminator rather than to the beginning of the string..)
The mighty mountain Heathfield labors, and great Heaves are heard on
Earth:
The Natives stand a-wonderin' what this presages, whether boon, or
dearth:
The storm clouds gather on the peak, no man dares show his face:
Heathfield announces an idea to the assembled people in this place.
It's "return a pointer to the end and not to the beginning"
The Volcano has but Popp'd, and out comes...almost nothing.
Again, I must agree that the const inconsistency with strchr is a bit of
a wart. But the input is const purely to constitute a promise that the
function won't write to the input string. The return value is non-const
because strchr would otherwise be a real pain to use. How could it be
done better?
But Heathfield says so, and it must of Needs be true:
This is the best of all possible worlds, there is no point in Rue:
Don't dream, don't hope, you're not the Pope, you are but a sot and
Bum
Heathfield knows this of you, because that's what he's become.
As for strfind, that's not C's problem. Take it up with the vendor.
To my mind, the sprintf function does not have serious buffer problems.
So lo! Heathfield's code has sprung a secret Leak:
But because he's the boss, no man may dare to speak.
It sprintsf bytes on adjacent pages, the debugger he but rages,
Why did this guy use such a feature, and will it to the ages?
His coworkers say, hey hey hey, you'd better hide your rage away:
The Boss wrote dat code back in his high and palmy Day.
If he hears you you're for the chop, better just rewrite the Code
Secretly and in silent hope you won't be the fall guy not his Toad.
Nevertheless, some people obviously disagree, and C99 provides snprintf
for such people.
The scanf function is basically a mess, and is rarely used correctly. I
am at a loss to understand why it is introduced so early in programming
texts.
The strtok function is of limited use, but there are times when it is
just the ticket. It would be better, however, for it to take a state
pointer. I'm not convinced that its interface is particularly non-intuitive.
And when he doubles a negative, the trouble really starts:
His meaning is conceal'd, it gets out in Fits, and Starts.
