Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 18 Jun 1998 23:01:30 -0500 (CDT)
From:      Joel Ray Holveck <joelh@gnu.org>
To:        richard@cogsci.ed.ac.uk
Cc:        imp@village.org, tlambert@primenet.com, current@FreeBSD.ORG
Subject:   Re: Bogus errno twiddling by lstat...
Message-ID:  <199806190401.XAA07310@detlev.UUCP>
In-Reply-To: <22587.199806172313@cockburn.cogsci.ed.ac.uk> (message from Richard Tobin on Thu, 18 Jun 1998 00:13:05 %2B0100)
References:   <22587.199806172313@cockburn.cogsci.ed.ac.uk>

next in thread | previous in thread | raw e-mail | index | archive | help
>> No.  When a system call returns success, the value of errno is
>> undefined.
> No!  A successful system call leaves it *unchanged*.  From intro(2):
>> Successful calls never set errno; once set, it remains
>> until another error occurs.

You are technically correct-- but this is not relevant to Jordan's
issue, because of the distinction between system calls and library
routines.  You quoted the intro to system calls.  In Jordan's example,
there was an error in a system call (specifically,
open("/etc/malloc.conf",...))-- but it is handled by the printf()
library routine.

> I believe ANSI C has a similar requirement.

Rather the opposite.  ISO C requires that nothing set errno to zero,
but may fiddle with it all they want otherwise.  (I haven't examined
the ANSI spec on the issue, but it is similar if not identical.)

> You should only examine errno after an error, but you are allowed to
> have had intervening successful system calls.

Yes, but there was a failed system call (specifically,
open("/etc/malloc.conf", ...)) intervening.

Happy hacking,
joelh

-- 
Joel Ray Holveck - joelh@gnu.org - http://www.wp.com/piquan
   Fourth law of programming:
   Anything that can go wrong wi
sendmail: segmentation violation - core dumped

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199806190401.XAA07310>