Return to BSD News archive
Newsgroups: comp.os.386bsd.development Path: sserve!newshost.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!agate!howland.reston.ans.net!gatech!news.byu.edu!cwis.isu.edu!fcom.cc.utah.edu!cs.weber.edu!terry From: terry@cs.weber.edu (A Wizard of Earth C) Subject: Re: File Truncation Philosophy Message-ID: <1993Apr22.013557.12767@fcom.cc.utah.edu> Sender: news@fcom.cc.utah.edu Organization: Weber State University (Ogden, UT) References: <C5LJ2u.1Ep@sugar.neosoft.com> <1993Apr18.012731.23976@fcom.cc.utah.edu> <C5t8Ft.EE8@sugar.neosoft.com> Date: Thu, 22 Apr 93 01:35:57 GMT Lines: 128 In article <C5t8Ft.EE8@sugar.neosoft.com> peter@NeoSoft.com (Peter da Silva) writes: >In article <1993Apr18.012731.23976@fcom.cc.utah.edu> terry@cs.weber.edu (A Wizard of Earth C) writes: >> No more than a reasonable application will care if signal sets aren't >> contiguous in Posix signals so that a for loop doing sigest()'s can't >> ever work. > >I wouldn't ever write a loop that trapped signals I wasn't prepared to handle. >That's horrible coding practice. Bah, Humbug! The idea is not to trap signals, but to untrp signals in a child process whose trap values (like SIG_IGNORE) where inherited from the parent; the problem is *restoring* the default action for each signal: ] After a fork(2V), or vfork(2) the child inherits all sig- ] nals, the signal mask, the signal stack, and the ] restart/interrupt and reset-signal-handler flags. The problem is that this is no longer simple under Posix; however, there *is* a correct way to do it that is guaranteed to be portable, where the normally expected "for" loop is not. >> Seriously, the return codes from "system" and "exec" need to be meaningful >> in all cases; that means documented, so that failures can be trapped. > >Again, you need to trap failures you can handle, and abend or failsoft on >failures you can't. Exactly my point -- limit the types of failures that can occur so that they can be trapped. Not only does this give us a well defined system interface that behaves in a predictable way, it makes systems with bogus error returns obvious (by way of "abend or failsoft"). All software written to the interface will run the same on all systems with the interface. That is the point of Posix. >Limiting errno values because some broken program might >mess up when it gets ETXTBSY or (for that matter) EMACS (Editor too big :>) >is a bad idea. No matter *what* POSIX says, any program that assumes the >set of possible error returns won't increase is broken. It shouldn't assume that the error set will not increase; however, ETXTBSY is an antiquated error whose use should be deprecated (and eliminated where possible -- and it's definitely possible on 386BSD if it's done "right"). Besides, a program should not have to know the failure recovery procedure for something that can be auto-recovered by the system software. >> What do you do in a program that returns an unexpected failure mode if >> the only code you have written deals with expected failure modes? > >Broken code is always a problem. If you limit the scope of the environment, there will be less broken code (I know; this begs the question regarding portability of code, like you can really be said to have "portable" software if it runs on a Compaq and and IBM machine under DOS). Personally, I'm torn between condemning it as a crutch and acclaiming it for freeing me from "fixing" bad code. >> I can't have exec() or open return ETXTBSY when it can never happen >> elsewhere > >What do you mean "it can never happen elsewhere"? It happens on existing >systems right now! Only very, very old ones, and ones with an "unfixed" MACH VM system. >> Better to "just work" in the kernel by copying to swap and retrying than >> to return any error in a case that would normally result in ETXTBSY were >> the kernel not trapping and handling the swap store workaround for you. > >I disagree. Adding complexity to the kernel (and chewing up swap space) to >cater to broken code is bogus. It's doubly bogus when you can legitimately >treat it as any other mandatory lock. If this i true, then it should actually assert a lock (so we can replace it with a Mutex for an SMP implementation), and there should be a locking system in place that is otherwise generally useful. There isn't any lock subsystem burrently in the kernel, and I'm too close to one at work to provide one... I can, however, do the VM fix without any conflict of interest. >> In my opinion *only* reasonable applications will have problems! It's >> only the *reasonable* applications that trap and handle errors in the first >> place; > >I'm sorry, but there are two primary rules violated here: > > 1. Don't trap errors you don't know how to handle. Not doing this; just trapping the ones I know about and suprising the hell out of the user when an otherwise recoverable, but unfortunately "unique" to the target system, error occurs, instead of just running. There is a rule being violated here, but it is the "rule of least astonishment", not the "rule of error trapping". Simply stated: Rule of least astonishment: Software should always act in such a way as to not suprise the user with the results of his actions. > 2. Don't assume that new types of errors won't show up. Not doing this, either; just trying to do preemptive damage control. This is in line with the corollary to the "rule of error trapping": Rule of error trapping: Don't trap error conditions you can't recover from. Corollary: Don't change an existing system so that it generates errors which are not trapped in existing software. You may make the existing software violate the "rule of error trapping". Terry Lambert terry@icarus.weber.edu terry_lambert@novell.com --- Any opinions in this posting are my own and not those of my present or previous employers. -- ------------------------------------------------------------------------------- "I have an 8 user poetic license" - me Get the 386bsd FAQ from agate.berkeley.edu:/pub/386BSD/386bsd-0.1/unofficial -------------------------------------------------------------------------------