svn commit: r184511 - head/lib/libc/gen

[Bruce Evans]

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