Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!bloom-beacon!bu-cs!encore!bzs@xenna From: bzs@xenna (Barry Shein) Newsgroups: comp.unix.wizards Subject: Re: checking close's return value Message-ID: <3715@encore.UUCP> Date: 25 Sep 88 00:35:50 GMT References: <20981@watmath.waterloo.edu> <1988Sep20.230150.7574@utzoo.uucp> <1213@unmvax.unm.edu> Sender: news@encore.UUCP Reply-To: bzs@xenna (Barry Shein) Organization: Encore Computer Corp Lines: 31 In-reply-to: mike@turing.unm.edu (Michael I. Bushnell) For years I've suggested from time to time that there should be a signal assigned for I/O errors which is by default OFF but can be enabled calling signal(). It should call the signal handler with the fd that caused the signal and the errcode it would have returned to the call that generated it (possibly some indication of the system call tho that might be hard.) The advantage is that you don't have to wrap all your I/O's with checks for errors (although I suppose there's still the grey area of short read/writes, I think semantics can be worked out for that with a little work.) Another advantage (similar) is that I can simply add a few lines to an existing program (like cat) and now check errors without hunting down every place it does I/O. More importantly, I don't need the souces to a library to add error checking (assuming I can return sanely.) The disadvantages (and implementation difficulties) are several, the worst being derived from the fact that the error will not be detected until all I/O physically completes. This means that I could, if nothing is done to prevent it, close a file and later receive a signal on that fd that there was an I/O error even tho by now I have it opened to a different file, very confusing. I suppose one semantic requirement might be that if the signal is enabled then a close() automaticallly implies an fsync() first, at any rate I don't think it's too much of a rat's nest, I didn't say the change was trivial. I dunno, if it's useful for SIGFPE it seems similarly useful for I/O. P.S. Yes, I am fully aware of what a SYNAD is. -Barry Shein, ||Encore||