From owner-freebsd-hackers Sat Jul 25 19:07:24 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id TAA25691 for freebsd-hackers-outgoing; Sat, 25 Jul 1998 19:07:24 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.15.68.22]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id TAA25671; Sat, 25 Jul 1998 19:07:19 -0700 (PDT) (envelope-from bde@godzilla.zeta.org.au) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.7/8.8.7) id MAA29472; Sun, 26 Jul 1998 12:06:52 +1000 Date: Sun, 26 Jul 1998 12:06:52 +1000 From: Bruce Evans Message-Id: <199807260206.MAA29472@godzilla.zeta.org.au> To: current@FreeBSD.ORG, dag-erli@ifi.uio.no, hackers@FreeBSD.ORG Subject: Re: sysexits Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >The style(9) man page recommends the use of values defined in > to indicate failure conditions. However, there is no That's a bug in style(9) :-)/2. The only non-contrib'ed 4.4-Lite source files that use it are rmail/rmail.c, mail.local/mail.local.c and sccs/sccs.c. >predefined value for what is probably the most common error condition, >at least in some applications - a failed malloc(), calloc() or >realloc(). I therefore suggest adding the constant EX_NOMEM, with the What's wrong with errx(1, "[mcre]alloc failed")? The error string will be understood by most humans and approximately 0 progams. EX_NOMEM will be understood by few humans and approximately 1 program (sendmail, but only after you change it to recognise the new error). Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message