NetBSD Problem Report #45112

From dholland@netbsd.org  Sun Jul  3 19:05:17 2011
Return-Path: <dholland@netbsd.org>
Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11])
	by www.NetBSD.org (Postfix) with ESMTP id 8459E63CA00
	for <gnats-bugs@gnats.NetBSD.org>; Sun,  3 Jul 2011 19:05:17 +0000 (UTC)
Message-Id: <20110703190517.7A57814A10E@mail.netbsd.org>
Date: Sun,  3 Jul 2011 19:05:17 +0000 (UTC)
From: dholland@netbsd.org
Reply-To: dholland@netbsd.org
To: gnats-bugs@gnats.NetBSD.org
Subject: cgdconfig can return -1 from main
X-Send-Pr-Version: 3.95

>Number:         45112
>Category:       bin
>Synopsis:       cgdconfig can return -1 from main
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    bin-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sun Jul 03 19:10:00 +0000 2011
>Last-Modified:  Mon Jul 04 16:05:02 +0000 2011
>Originator:     David A. Holland
>Release:        current of 20110703
>Organization:
>Environment:
n/a
>Description:

   The end of main() directly returns the return value of various
   operation functions, some of which can return -1 on error. However,
   just as one should not call exit(-1), one should not return -1 from
   main.

   Some of these functions may return errnos as well, which doesn't
   seem like a good idea to mix with ordinary 0/1 exit codes.

   This issue was actually noted by jruoho in chat.

>How-To-Repeat:

   code reading

>Fix:

   At the bottom of main, check for -1 and return 2 instead? Also, if
   there's some real reason to return errnos, perhaps offset them by
   16 or something... also, if so these exit codes should be
   documented, which they aren't.

>Audit-Trail:
From: Jukka Ruohonen <jruohonen@iki.fi>
To: gnats-bugs@NetBSD.org
Cc: dholland@NetBSD.org
Subject: Re: bin/45112: cgdconfig can return -1 from main
Date: Mon, 4 Jul 2011 19:00:10 +0300

 On Sun, Jul 03, 2011 at 07:10:01PM +0000, dholland@NetBSD.org wrote:
 >    At the bottom of main, check for -1 and return 2 instead? Also, if
 >    there's some real reason to return errnos, perhaps offset them by
 >    16 or something... also, if so these exit codes should be
 >    documented, which they aren't.

 Indeed, do something useful with the exit codes, like print a warning; 
 at least the following is related: PR bin/28624.

Home	PR Database Search