errno on syscall return (Was: Re: ENOTTY error when executing cp(1))

Tim Oldham tjo at fulcrum.bt.co.uk
Fri Sep 29 03:01:06 AEST 1989


In article <250 at paralogics.UUCP> shaw at 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 at fulcrum.bt.co.uk  or  ...!mcvax!ukc!axion!fulcrum!tjo
#include	<stdisclaim>
Why have coffee, when caffeine tastes this good?



More information about the Comp.unix.wizards mailing list