Date: Wed, 23 Sep 1998 02:39:51 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: tinguely@plains.NoDak.edu (Mark Tinguely) Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: FYI: function call failures Message-ID: <199809230239.TAA15572@usr06.primenet.com> In-Reply-To: <199809221907.OAA07181@plains.NoDak.edu> from "Mark Tinguely" at Sep 22, 98 02:07:14 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> *** FYI. for S/N concerns, please take comments about paper to -chat *** > > from comp.arch a reference (http://www.ices.cmu.edu/ballista/ftcs98/) to > a test of function call failures. FreeBSD did not fair too well compared > to other OSes. > > *** FYI. for S/N concerns, please take comments about paper to -chat *** This is not a comment about the paper; it is a comment about your statement that "FreeBSD did not fair too well compared to other OSes". Unfortunately, I'll have to examine the metric you are holding out in order to make my comment. They are counting abort() traps as a result of passing bad pointers to library functions and system calls as "failures". This is because: ...In this scale, the response lies in one of six categories: Catastrophic (the system crashes or hangs), Restart (the test process hangs), Abort (the test process terminates abnormally, i.e. "core dump"), Silent (the test process exits without an error code, but one should have been returned), Hindering (the test process exits with an error code not relevent to to the situation), and Pass (the module exits properly, possibly with an appropriate error code). Silent and Hindering failures are currently not found by Ballista. In other words: o if you SIGSEGV from a NULL pointer dereference, you are a "bad" OS o if you silently accept bogus arguments without crashing or otherwise indicating an error, you are a "good" OS o if you silently accept bogus arguments that should have resulted in an error, but didn't, you are a "good" OS To wit, this is a rehash of the following two long-lived threads: o FreeBSD should check for invalid pointer arguments to functions like strcmp and strcpy, and otherwise engage in idiot-proofing code, even though idiots who will call these functions incorrectly will not recognize an error response when it bites them on the arse. o FreeBSD should never call abort, even when data outside the process virtual address space is referenced, since even though doing so will pinpoint the exact line of code where the problem exists, while at the same time preventing cascade failures (like launching all nukes if a single failure causes one nuke to be launched), we prefer to trust the programmers to always check the strcpy(3) return values, because we know that all programs check for error returns for libc functions (yeah, right). If you can't tell yet, I disagree with your statement about how well FreeBSD did or did not fare. There is a particular, and *desirable* length to that blue bar for a POSIX compliant OS, though they fail to state where that boundary is, unfortunately, and FreeBSD had no catastropic errors, nor any Restart errors. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199809230239.TAA15572>