Date: Fri, 16 Jul 1999 00:02:55 -0500 (CDT) From: Kevin Day <toasty@dragondata.com> To: dillon@apollo.backplane.com (Matthew Dillon) Cc: green@FreeBSD.ORG (Brian F. Feldman), a.reilly@lake.com.au (Andrew Reilly), dcs@newsguy.com (Daniel C. Sobral), lyndon@orthanc.ab.ca, freebsd-hackers@FreeBSD.ORG Subject: Re: Swap overcommit Message-ID: <199907160502.AAA28122@celery.dragondata.com> In-Reply-To: <199907160452.VAA15530@apollo.backplane.com> from Matthew Dillon at "Jul 15, 1999 09:52:56 pm"
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. > I thought I saw this somewhere too, but I thought it was more of a case that it was somewhere *inside* read that errno had to be preserved. i.e. errno gets set somewhere at the top of the code, and if it was already set at a certain point, failure was expected, and to pass along the original errno, not the new one. Or perhaps we're sharing a hallucination. :) Kevin 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?199907160502.AAA28122>