[net.sources.bugs] bug in ctype.c, and a replacement for it

lynx@qantel.UUCP (D.N. Lynx Crowe@ex2207) (10/23/86)

The character classification program "ctype.c" recently posted to the net
has a bug in it:  the headings for the columns are in the wrong order.

I decided that what I wanted was a complete count of all characters, not
just those below octal 200, so I put together a replacement for it, ccount.c,
which I've posted to net.sources.


-- 
----------------------------------------------------------
D.N. Lynx Crowe {dual, hplabs, lll-crg, ptsfa}!qantel!lynx
----------------------------------------------------------
"Just say 'No' -- to Government"
----------------------------------------------------------

rsk@j.cc.purdue.edu (Wombat) (10/25/86)

In article <725@qantel.UUCP> lynx@qantel.UUCP (D.N. Lynx Crowe@ex2207) writes:
>The character classification program "ctype.c" recently posted to the net
>has a bug in it:  the headings for the columns are in the wrong order.
>
>I decided that what I wanted was a complete count of all characters, not
>just those below octal 200, so I put together a replacement for it, ccount.c,
>which I've posted to net.sources.

Four things; first off, it is common courtesy to report such bugs in
posted software to the author *first*, thus giving that author the
opportunity to correct them in whatever way the author feels best.
There are exceptions--for instance, truly nasty bugs in important
pieces of software.  This is not one of those cases.

Secondly, you do not specify what the "correct" order would be, or
why the given order is "wrong".

Thirdly, if you had bothered to correspond with the author (me), you
would have discovered that the author had already received a number
of suggestions about the program, one of which was to add the codes
above octal 200 [optionally].

Finally, even though you used nearly all my code in your program, you
make no mention of that in the source.  Fine--you don't *have* to;
but if I wrote a program that whose concept was completely derived from
another, and whose source code was almost completely taken from another,
I'd acknowledge the original author.  I think most folks on Usenet
would do the same.  I'm amazed and appalled at your actions in this matter.

-- 
Rich Kulawiec, j.cc.purdue.edu!rsk, rsk@j.cc.purdue.edu

lynx@qantel.UUCP (D.N. Lynx Crowe@ex2207) (10/27/86)

In article <2405@j.cc.purdue.edu> rsk@j.cc.purdue.edu.UUCP (Wombat) writes:
>In article <725@qantel.UUCP> lynx@qantel.UUCP (D.N. Lynx Crowe@ex2207) writes:
>>The character classification program "ctype.c" recently posted to the net
>>has a bug in it:  the headings for the columns are in the wrong order.
>>
>>I decided that what I wanted was a complete count of all characters, not
                 ^^^^^^^^^^^^^
>>just those below octal 200, so I put together a replacement for it, ccount.c,
>>which I've posted to net.sources.
>
>Four things; first off, it is common courtesy to report such bugs in
>posted software to the author *first*, thus giving that author the
>opportunity to correct them in whatever way the author feels best.
>There are exceptions--for instance, truly nasty bugs in important
>pieces of software.  This is not one of those cases.
>
>Secondly, you do not specify what the "correct" order would be, or
>why the given order is "wrong".

(The "correct" order is a matter of what the user decides is "right".)

>
>Thirdly, if you had bothered to correspond with the author (me), you
>would have discovered that the author had already received a number
>of suggestions about the program, one of which was to add the codes
>above octal 200 [optionally].
>
>Finally, even though you used nearly all my code in your program, you
>make no mention of that in the source.  Fine--you don't *have* to;
>but if I wrote a program that whose concept was completely derived from
>another, and whose source code was almost completely taken from another,
>I'd acknowledge the original author.  I think most folks on Usenet
>would do the same.  I'm amazed and appalled at your actions in this matter.
>
>-- 
>Rich Kulawiec, j.cc.purdue.edu!rsk, rsk@j.cc.purdue.edu

Well, thanks for the flames ...

By the time I'd gotten around to trying the code you'd posted I had lost
a return path to you, this makes it difficult to correspond.

As you may, or may not, have noticed, the code posted was what I found
that I needed, not intended to be "general", and posted as a quick fix
to what I got from the net.  Yes, it is a modified version of your code,
an I do apologize for not having attributed it to you.  That was an
unfortunate oversight which I regret occurred.

As to pointing out the error in your posting, that was partly the intent
of my posting.  If I had had your return path I would have indeed sent you
a note first.

Perhaps the next time I encounter bugs in posted code I will simply keep the
corrections to myself and avoid the flames.

-- 
----------------------------------------------------------
D.N. Lynx Crowe {dual, hplabs, lll-crg, ptsfa}!qantel!lynx
----------------------------------------------------------
"Just say 'No' -- to Government"
----------------------------------------------------------

mark@umcp-cs.UUCP (Mark Weiser) (10/29/86)

>In article <2405@j.cc.purdue.edu> rsk@j.cc.purdue.edu.UUCP (Wombat) writes:
>Four things; first off, it is common courtesy to report such bugs in
>posted software to the author *first*, thus giving that author the
>opportunity to correct them in whatever way the author feels best.
>There are exceptions--for instance, truly nasty bugs in important
>pieces of software.  This is not one of those cases.

I do not agree with this sentiment.  It is common usenet practice,
and also a courtesy to the other users of publically posted software,
to post bug fixes as well.  Who knows when the author will get around
to fixing the bugs, or posting the fixes or the new version?  And who
knows when some other user may need just this fix, however trivial,
that I just came up with?  Truly nasty bugs only?  If it costs
me an hour to fix, and a posting can save someone else that hour,
that is nasty enough for me.

I have sent code to net.sources, and gotten both postings and letters
with bugs back.  I found the postings particularly flattering: I
took them to mean that the poster thought my software sufficiently
important that the bug fixes (or improvements) ought to get around.
-mark
-- 
Spoken: Mark Weiser 	ARPA:	mark@maryland	Phone: +1-301-454-7817
CSNet:	mark@umcp-cs 	UUCP:	{seismo,allegra}!umcp-cs!mark
USPS: Computer Science Dept., University of Maryland, College Park, MD 20742

lwall@sdcrdcf.UUCP (Larry Wall) (10/29/86)

In article <2405@j.cc.purdue.edu> rsk@j.cc.purdue.edu.UUCP (Wombat) writes:
>Four things; first off, it is common courtesy to report such bugs in
>posted software to the author *first*, thus giving that author the
>opportunity to correct them in whatever way the author feels best.
>There are exceptions--for instance, truly nasty bugs in important
>pieces of software.  This is not one of those cases.

In article <4054@umcp-cs.UUCP> mark@umcp-cs.UUCP (Mark Weiser) responds:
>I do not agree with this sentiment.  It is common usenet practice,

There are other "common usenet practices" I wouldn't want to try to justify.

>and also a courtesy to the other users of publically posted software,
>to post bug fixes as well.

It is not a courtesy to confuse people.  When people apply "unauthorized"
patches, then "authorized" patches tend not to apply themselves correctly.

>Who knows when the author will get around to fixing the bugs, or posting
>the fixes or the new version?

This is a semi-valid point.  There needs to be some responsibility on both
sides.  Bug finders need to try to respect the author's wishes in this matter.
Authors should make known their wishes so they can be respected.  In all the
packages I send out, I explicitly say to relay bug fixes through me, and I
find that most people respect this.  If someone doesn't want to be responsible
for ongoing support, that should also be clearly stated.

On the other hand, I don't mind if people publish unauthorized patches,
as long as they are CLEARLY LABELLED as such, with directions on how to back
them out when the official patch comes out, and important enough to warrant
the extra work to back out the unofficial patch.  A bug report should also
be mailed to the author, so they can produce an official patch.

>And who knows when some other user may need just this fix, however trivial,
>that I just came up with?  Truly nasty bugs only?  If it costs
>me an hour to fix, and a posting can save someone else that hour,
>that is nasty enough for me.

Suppose you get and apply an unofficial patch, and then get the official one.
If it costs you an hour or some data when you apply the official patch
and it doesn't work, then you've lost your advantage.  If you get confused
and send a message off to the package maintainer saying "patch 23 didn't work",
then he or she gets to be confused for an hour as well, especially if the
unofficial patch didn't propagate to the maintainer's site.  Worse, if the
person posting the unofficial patch doesn't have a good grasp of portability
or the internals of your program, he can break the program in other subtle
but damaging ways.  He can tell you that A should be B, when in fact both
A and B should be there in #ifdefs.  He can screw up your malloc arena,
dereference null pointers, use ints where longs are appropriate, put in
buffers that overflow, reinvent wheels and make your program work twice as
hard as it needs to.  After all, it worked on his system when he tried it.
If he tried it.

All in the name of a quick fix.

The fact is that most bugs are trivial, and have workarounds.  If you
spend an hour tracking down a bug for which there is an obvious workaround,
then I think you've been satisfying your curiosity, which activity I would
not want to deprive you of, though I question your time management techniques.
If the workaround is not obvious, getting a note from the net saying what the
workaround is and that the bug is being looked at may be quite sufficient to
save you your hour's work.  If a temporary patch is included, it gives you
the option of applying it or not, but ONLY if you know it's a temporary patch.

>I have sent code to net.sources, and gotten both postings and letters
>with bugs back.  I found the postings particularly flattering: I
>took them to mean that the poster thought my software sufficiently
>important that the bug fixes (or improvements) ought to get around.

Yes, I find the postings flattering also (though the f key is right under the
r key, and maybe their finger just slipped :-).  However, one should never
assume that just because someone else has posted a patch, it has gotten
everywhere it ought to.  The package maintainer must STILL post an official
version of the patch, hopefully with a sequence number, so that when people get
official patch #28, and patchlevel.h says "#define PATCHLEVEL 24", they
know that they are missing patches 25-27.

Believe me, this happens all the time.  Usenet is not the most reliable
of networks, and even if it were, people still miss things.  Every time
I send out a patch for rn or patch or warp (and soon metaconfig, sigh) I get
a ton of messages saying "I'm missing patches n..m--please send."

As usual, the issue isn't black and white.  And as usual, 10% more effort
on everyone's part will clear up 90% of the confusion.  Just be clear where
you're coming from.  Laziness and impatience are the cardinal virtues of
programmers, but not of writers.

Larry Wall
{allegra,burdvax,cbosgd,hplabs,ihnp4,sdcsvax}!sdcrdcf!lwall