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!zaphod.mps.ohio-state.edu!menudo.uh.edu!uuneo!sugar!peter From: peter@NeoSoft.com (Peter da Silva) Subject: Re: File Truncation Philosophy Organization: NeoSoft Communications Services -- (713) 684-5900 Date: Wed, 21 Apr 1993 01:35:51 GMT Message-ID: <C5t8Ft.EE8@sugar.neosoft.com> References: <1993Apr16.044053.10665@fcom.cc.utah.edu> <C5LJ2u.1Ep@sugar.neosoft.com> <1993Apr18.012731.23976@fcom.cc.utah.edu> Lines: 49 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. > 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. 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. > 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. > 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! > 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. > 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. 2. Don't assume that new types of errors won't show up. -- Peter da Silva. <peter@sugar.neosoft.com>. `-_-' Oletko halannut suttasi tänään? 'U` Tarjoilija, tämä ateria elää vielä.