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