Date: Fri, 30 Aug 2002 13:47:48 -0500 From: Operations <csjp@sqrt.ca> 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> In-Reply-To: <200208300240.g7U2e1UO027819@freefall.freebsd.org>; from FreeBSD-gnats-submit@FreeBSD.org on Thu, Aug 29, 2002 at 07:40:01PM -0700 References: <200208300233.g7U2XB7F023811@xor.sqrt.ca> <200208300240.g7U2e1UO027819@freefall.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020830134748.A92009>