Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!uunet!mcsun!ukc!axion!fulcrum!tjo From: tjo@fulcrum.bt.co.uk (Tim Oldham) Newsgroups: comp.unix.wizards Subject: errno on syscall return (Was: Re: ENOTTY error when executing cp(1)) Message-ID: <302@cat.fulcrum.bt.co.uk> Date: 28 Sep 89 17:01:06 GMT References: <507@fdmetd.uucp> <2556@taux01.UUCP> <301@6sigma.UUCP> <109@harald.UUCP> <250@paralogics.UUCP> Reply-To: tjo@fulcrum.bt.co.uk (Tim Oldham) Organization: BT IT Systems, Birmingham, England Lines: 37 In article <250@paralogics.UUCP> shaw@paralogics.UUCP (Guy Shaw) writes: > >[ errno on return from system calls and mistakes made in coding ] >On the one hand, the mistakes I see are >all based on very natural assumptions - maybe those assumptions should be >made valid in future. The point is that when writing any code at all, you *mustn't* make assumptions. Most programmers' assumptions are based on their believing that code will work in a "sensible" fashion. Any given 2 people are likely to have different ideas about what "sensible" behaviour is, and so will make different assumptions. The behaviour of errno is well-defined, and strikes me as being sensible, but I obviously have a different idea of what "sensible" is to lots of other people. >So, maybe future versions of UNIX should *guarantee* that >errno will be set to garbage after all successful system calls. That will >flush out a lot of latent bugs, and those people who have been "lucky" >so far will learn quickly. It's a nice idea, but I get the horrible feeling it's too late, and would annoy people. What a shame. The lesson, of course, is to get it right to start with. Stop making assumptions, and understand the real behaviour. One last point: is one reason that so many people use system calls and not the equivalent library functions that errno isn't defined on return from, say, a failed fwrite()? Tim. -- Tim Oldham tjo@fulcrum.bt.co.uk or ...!mcvax!ukc!axion!fulcrum!tjo #includeWhy have coffee, when caffeine tastes this good?