Xref: utzoo comp.lang.c:26573 comp.software-eng:3062 Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!usc!samsung!uunet!mcsun!sunic!dkuug!iesd!iesd.auc.dk!fischer From: fischer@iesd.auc.dk (Lars P. Fischer) Newsgroups: comp.lang.c,comp.software-eng Subject: Re: C Community's Cavalier Attitude On Software Reliability Message-ID: Date: 5 Mar 90 01:00:52 GMT References: <7351@arcturus> <8212@hubcap.clemson.edu> Sender: news@iesd.auc.dk (UseNet News) Organization: Mathematics and Computer Science, University of Aalborg Lines: 16 In-reply-to: billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu's message of 2 Mar 90 19:41:07 GMT In article <8212@hubcap.clemson.edu> billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe, 2847 ) writes: > 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. The BUGS section is also intended to point out problems you, as a user, might have with a utility if you are not aware of limitations in the design or the implementation. It is good practice to point out implications of a design decision that the user might not be aware of. /Lars -- Lars Fischer, fischer@iesd.auc.dk | Q: How does a project get to be one CS Dept., Univ. of Aalborg, DENMARK. | year late? A: One day at a time.