From owner-freebsd-bugs@FreeBSD.ORG Sun Sep 12 20:11:08 2004 Return-Path: Delivered-To: freebsd-bugs@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F1AEC16A4F1 for ; Sun, 12 Sep 2004 20:11:07 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id C9A0C43D45 for ; Sun, 12 Sep 2004 20:11:07 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.11/8.12.11) with ESMTP id i8CKB7wO028236 for ; Sun, 12 Sep 2004 20:11:07 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.12.11/8.12.11/Submit) id i8CKB7aI028235; Sun, 12 Sep 2004 20:11:07 GMT (envelope-from gnats) Date: Sun, 12 Sep 2004 20:11:07 GMT Message-Id: <200409122011.i8CKB7aI028235@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org From: Giorgos Keramidas Subject: Re: bin/71651: [PATCH] cron may attept to close unopened file X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Giorgos Keramidas List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Sep 2004 20:11:08 -0000 The following reply was made to PR bin/71651; it has been noted by GNATS. From: Giorgos Keramidas To: Dan Lukes Cc: bug-followup@freebsd.org Subject: Re: bin/71651: [PATCH] cron may attept to close unopened file Date: Sun, 12 Sep 2004 23:01:55 +0300 On 2004-09-12 16:15, Dan Lukes wrote: > > >Number: 71651 > >Category: bin > >Synopsis: [PATCH] cron may attept to close unopened file > >Confidential: no > >Severity: serious > >Priority: low > >Responsible: freebsd-bugs > >State: open > >Quarter: > >Keywords: > >Date-Required: > >Class: sw-bug > >Submitter-Id: current-users > >Arrival-Date: Sun Sep 12 14:20:22 GMT 2004 > >Closed-Date: > >Last-Modified: > >Originator: Dan Lukes > >Release: FreeBSD 5.3-BETA3 i386 > >Organization: > Obludarium > >Environment: > System: FreeBSD kulesh.obluda.cz 5.3-BETA3 FreeBSD 5.3-BETA3 #8: Sun Sep 5 07:06:40 CEST 2004 dan@kulesh.obluda.cz:/usr/obj/usr/src/sys/Dan i386 > usr.sbin/cron/lib/misc.c,v 1.11 2002/08/04 04:32:27 tjr > usr.sbin/cron/cron/cron.c,v 1.15 2004/05/16 19:29:33 yar > usr.sbin/cron/cron/do_command.c,v 1.22 2004/05/16 19:29:33 yar > > >Description: > usr.sbin/cron/lib/misc.c:413: warning: 'deny' might be used uninitialized in this function > > It's sign of true bug. When fopen of ALLOW_FILE fail for other than ENOENT > reason, then "goto out" apply then 'if (deny)' is evaluated and > 'fclose(deny)' may be called athought 'deny' is uninitialized variable. The check to avoid calling fclose() with NULL is already there. You just have to make sure that `allow' and `deny' are always initialized to NULL to let it work as expected :-) %%% Index: misc.c =================================================================== RCS file: /home/ncvs/src/usr.sbin/cron/lib/misc.c,v retrieving revision 1.11 diff -u -r1.11 misc.c --- misc.c 4 Aug 2002 04:32:27 -0000 1.11 +++ misc.c 12 Sep 2004 19:55:31 -0000 @@ -410,7 +410,8 @@ allowed(username) char *username; { - FILE *allow, *deny; + FILE *allow = NULL; + FILE *deny = NULL; int isallowed; isallowed = FALSE; @@ -421,9 +422,6 @@ if ((deny = fopen(DENY_FILE, "r")) == NULL && errno != ENOENT) goto out; Debug(DMISC, ("allow/deny enabled, %d/%d\n", !!allow, !!deny)) -#else - allow = NULL; - deny = NULL; #endif if (allow) %%% > struct tm otztm; /* time in the old time zone */ > - int otzminute, otzhour, otzdom, otzmonth, otzdow; > + int otzminute = otzminute, /* "init" to avoid "might be used uninitialized" warning */ > + otzhour = otzhour, otzdom = otzdom, > + otzmonth = otzmonth, otzdow = otzmonth; Please don't use this. There's probably a true bug hidden here. Hiding it is not good. > if (ch != EOF) { > - register FILE *mail; > + register FILE *mail = mail; /* "init" to avoid "might be used uninitialized" warning */ Use NULL as the initialization of (FILE *) objects. If they are indeed used before a proper initialization is done this will expose the true bugs and let us fix them ;-) - Giorgos