From owner-freebsd-bugs Fri Aug 30 11:25:28 2002 Delivered-To: freebsd-bugs@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A061937B400 for ; Fri, 30 Aug 2002 11:25:24 -0700 (PDT) Received: from staff.seccuris.com (staff.seccuris.com [204.112.0.40]) by mx1.FreeBSD.org (Postfix) with SMTP id CC38243E65 for ; Fri, 30 Aug 2002 11:25:18 -0700 (PDT) (envelope-from csjp@sqrt.ca) Received: (qmail 92083 invoked by uid 1006); 30 Aug 2002 18:47:48 -0000 Date: Fri, 30 Aug 2002 13:47:48 -0500 From: Operations To: FreeBSD-gnats-submit@FreeBSD.org, freebsd-bugs@FreeBSD.org Cc: mkb@mukappabeta.de Subject: Re: bin/42179: [patch] fetch: memory leak and general optimizations Message-ID: <20020830134748.A92009@staff.seccuris.com> References: <200208300233.g7U2XB7F023811@xor.sqrt.ca> <200208300240.g7U2e1UO027819@freefall.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200208300240.g7U2e1UO027819@freefall.freebsd.org>; from FreeBSD-gnats-submit@FreeBSD.org on Thu, Aug 29, 2002 at 07:40:01PM -0700 Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I think the core issue of this PR was the fact that the transfer buffer was not being un-allocated by fetch after it was done with it. Thus "memory leak". @@ -535,13 +539,16 @@ } signal(SIGINFO, SIG_DFL); + /* free transfer buffer */ + free(buf); + Furthermore, there is absolutely nothing absurd about removing 16 global variables and replacing them with with a single integer that can store up to 32 switches. if (integer == 1) typically would cause the assembler to produce: cmpl $1,op /* typically followed by a jump of some sort. */ jne some_label if (integer & mask) typically would cause the assembler to produce: andl $1,%eax testl %eax,%eax /* typically followed by a jump of some sort. */ The major difference is one has a slew global variables and the other does not. Saying the bit ops produce significantly more code then a straight integer comparisons is not entirely accurate. Arguing otherwise doesn't lend much credibility to your comments, as far as programming is concerned anyway. I dont see anything "LSD'ish" about this patch at all. Regards To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message