Date: Thu, 15 Jul 1999 23:45:29 -0400 (EDT) From: "Brian F. Feldman" <green@FreeBSD.org> To: Matthew Dillon <dillon@apollo.backplane.com> 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: <Pine.BSF.4.10.9907152343060.47920-100000@janus.syracuse.net> In-Reply-To: <199907160300.UAA14677@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 15 Jul 1999, Matthew Dillon wrote:
>
> 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?!?
>
> -Matt
> Matthew Dillon
> <dillon@backplane.com>
>
>
> To Unsubscribe: send mail to majordomo@FreeBSD.org
> with "unsubscribe freebsd-hackers" in the body of the message
>
Brian Fundakowski Feldman _ __ ___ ____ ___ ___ ___
green@FreeBSD.org _ __ ___ | _ ) __| \
FreeBSD: The Power to Serve! _ __ | _ \._ \ |) |
http://www.FreeBSD.org/ _ |___/___/___/
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?Pine.BSF.4.10.9907152343060.47920-100000>