C Community's Cavalier Attitude On Software Reliability

[Bob Goudreau]

In article <8212 at hubcap.clemson.edu>,
billwolf%hazel.cs.clemson.edu at hubcap.clemson.edu (William Thomas Wolfe,
2847 ) writes:
>    If a currency conversion program is based on the exchange rates
>    as of a given date, then this is a continuation of the specification 
>    which does not belong in the DEFECTS section.   

I see -- your latest strawman is that the manual page for units(1) does
not conform to *your* idea of proper documentation format.  Well, big
f---ing deal.  Many of us find it *helpful* to have caveats and bugs
called out separately instead of buried in the "specification".  ("It
ain't a bug -- it's a *Feetchur*!")  But I see your strategy -- your
new attack draws attention away from your original complaint about
units(1), which must have embarassed you horribly when you found out
about floating (gasp!) currency exchange rates.
 
>    Under no circumstances should a DEFECTS section contain flippant
>    comments such as "I tinker a lot, so things break, but then I fix
>    them, hooray", "Not bloody likely", or other comments which indicate
>    a cavalier attitude toward software reliability.  
> 
>    DEFECTS sections exist for the purpose of listing known areas in
>    which an implementation does not correspond to the specification,
>    along with potential workarounds (if any) and the estimated date
>    of repair.  Now compare this with your typical Unix BUGS section.

Well, I have, and except for the "estimated date of repair" part, I
find that most UNIX manpage BUGS sections already seem to offer just
this information.  (BTW, the EDoR of a bug is *not* a documentation
issues, a C issue, a UNIX issue, or even a programming issue.  It's
a product/release management issue.  Only after an EDoR has been
decided can it be documented.)

As for your examples, the ones with "flippant comments" seem to be
still more strawmen for your pathetic argument.  What the heck is
dab(1) anyway?  Are you perhaps confusing manpages for a real product
with manpages for locally programmed (and documented) extensions to
the system?

------------------------------------------------------------------------
Bob Goudreau				+1 919 248 6231
Data General Corporation
62 Alexander Drive			goudreau at dg-rtp.dg.com
Research Triangle Park, NC  27709	...!mcnc!rti!xyzzy!goudreau
USA