Date: Thu, 15 Jul 1999 21:52:56 -0700 (PDT) From: Matthew Dillon <dillon@apollo.backplane.com> To: "Brian F. Feldman" <green@FreeBSD.ORG> Cc: Andrew Reilly <a.reilly@lake.com.au>, "Daniel C. Sobral" <dcs@newsguy.com>, lyndon@orthanc.ab.ca, freebsd-hackers@FreeBSD.ORG Subject: Re: Swap overcommit Message-ID: <199907160452.VAA15530@apollo.backplane.com> References: <Pine.BSF.4.10.9907152343060.47920-100000@janus.syracuse.net>
next in thread | previous in thread | raw e-mail | index | archive | help
:> The are dozens of libc routines which call malloc internally and return
:> allocated storage. strdup(), opendir(), fopen(), setvbuf(), asprintf(),
:> and so forth. Dozens. And while we might check some of these for NULL,
:> we don't check them all, and the ones we do check we tend to conclude
:> a failure other then a memory failure. We would assume that the directory
:> or file does not exist, for example. How many programmers check errno
:> after such a failure? Very few. How many programmers bother to even
:> *clear* errno before making these calls (since some system calls do not
: ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
:We're not supposed to have to clear errno unless we have to explicitly
:test if it has changed. We're not supposed to clear it before any system
:call which could possibly fail and set errno.
:
:> set errno if it already non-zero). Virtually nobody.
: ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
:Erm... WTF?!?! If so, why the HELL are we doing that?!?
No, wait, I got that wrong I think.
Oh yah, I remember now. Hmm. How odd. I came across a case where
read() could return -1 and not set errno properly if errno
was already set, but a perusal of the kernel code seems to indicate
that this can't happen. Very weird.
-Matt
Matthew Dillon
<dillon@backplane.com>
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199907160452.VAA15530>