Date: Sat, 1 Nov 2008 22:32:12 +1100 (EST) From: Bruce Evans <brde@optusnet.com.au> To: Robert Watson <rwatson@freebsd.org> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r184511 - head/lib/libc/gen Message-ID: <20081101220954.B12551@delplex.bde.org> In-Reply-To: <200810311514.m9VFEfi9083785@svn.freebsd.org> References: <200810311514.m9VFEfi9083785@svn.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 31 Oct 2008, Robert Watson wrote: > Log: > In example use of err(3) and errx(3), use sysexits(3) constants. Use of sysexits is a style bug here too (see a reply to the corresponding change in style.9 for more details). > Modified: head/lib/libc/gen/err.3 > ============================================================================== > --- head/lib/libc/gen/err.3 Fri Oct 31 15:11:01 2008 (r184510) > +++ head/lib/libc/gen/err.3 Fri Oct 31 15:14:40 2008 (r184511) > @@ -178,15 +178,16 @@ or a null pointer > Display the current errno information string and exit: > .Bd -literal -offset indent > if ((p = malloc(size)) == NULL) > - err(1, NULL); > + err(EX_OSERR, NULL); > if ((fd = open(file_name, O_RDONLY, 0)) == -1) > - err(1, "%s", file_name); > + err(EX_NOINPUT, "%s", file_name); These have other style bugs -- a null or incomplete error message makes a sysexits error code almost useful. Normal for malloc failure is errx(1, "malloc failed"). This intentionally uses errx() instead of err() since the usual error ENOMEM for malloc() failure is considered useless, and/or the code is supposed to be portable to systems where malloc() is not guaranteed to set errno on failure. FreeBSD's actually malloc() claims to always set errno to ENOMEM on error. It seems to actually do this. This involves clobbering any possibly-more useful different errno set by mmap() etc. after preserving the original errno in a nonstandard place. Apart from this, with malloc() being even more in userland and with possibly more complicated failure modes, the printing error code might be more useful. (Except of couse malloc9) neverl fails :-), and when it does the MALLOC_OPTIONS="A" mistake makes it abort.) Also, with malloc() more in userland, EX_OSERR for malloc failure is wronger than before. Normal for open failure is err(1, "cannot open %s", file_name);. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20081101220954.B12551>