From owner-freebsd-hackers Mon Dec 18 11:11:22 2000 From owner-freebsd-hackers@FreeBSD.ORG Mon Dec 18 11:11:14 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from gw.nectar.com (gw.nectar.com [208.42.49.153]) by hub.freebsd.org (Postfix) with ESMTP id 48C6F37B400 for ; Mon, 18 Dec 2000 11:11:14 -0800 (PST) Received: from hamlet.nectar.com (hamlet.nectar.com [10.0.1.102]) by gw.nectar.com (Postfix) with ESMTP id 4735C193E1; Mon, 18 Dec 2000 13:11:12 -0600 (CST) Received: (from nectar@localhost) by hamlet.nectar.com (8.11.1/8.9.3) id eBIJBCK65204; Mon, 18 Dec 2000 13:11:12 -0600 (CST) (envelope-from nectar@spawn.nectar.com) Date: Mon, 18 Dec 2000 13:11:12 -0600 From: "Jacques A. Vidrine" To: Warner Losh Cc: hackers@FreeBSD.ORG Subject: Re: Why not another style thread? (was Re: cvs commit: src/lib/libc/gen getgrent.c) Message-ID: <20001218131112.B65143@hamlet.nectar.com> References: <20001217151509.A63051@hamlet.nectar.com> <20001217151735.D54486@holly.calldei.com> <20001217153129.B63080@hamlet.nectar.com> <20001217153656.F54486@holly.calldei.com> <20001217155648.C63080@hamlet.nectar.com> <20001217160442.H54486@holly.calldei.com> <20001217170316.A63227@hamlet.nectar.com> <200012180501.WAA87838@harmony.village.org> <20001218123108.A65143@hamlet.nectar.com> <200012181840.LAA92561@harmony.village.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200012181840.LAA92561@harmony.village.org>; from imp@village.org on Mon, Dec 18, 2000 at 11:40:43AM -0700 X-Url: http://www.nectar.com/ Sender: nectar@nectar.com Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, Dec 18, 2000 at 11:40:43AM -0700, Warner Losh wrote: > In message <20001218123108.A65143@hamlet.nectar.com> "Jacques A. Vidrine" writes: > : None taken. It is however a simple and safe optimization, with no > : apparent downsides. It has the same attraction as using bit shifts > : instead of multiplication/division, or saving the value from a function > : call that will be needed again later, even if you know the function call > : is trivial. > > You are trading a test against zero and code obfuscation against a > function call. The function call is typically much less than even a > multiplication or division would be. You get clearer, easier to read > code that is smaller by allowing free to do its job and not trying to > optimize things. Ever notice that you tend to send more email when you should be studying for a final? /* Case 1 */ /* Case 2 */ if (data) vs. free(data) free(data); I don't see that Case 1 obfuscates anything. In some cases I find it clearer: Case 1 implies that maybe no memory was allocated. Case 2 seems to imply that memory was indeed allocated. > I guess I tend to think 'This needs to be freed, let free deal with > the details so I won't have to be bothered with them.' Function > abstraction is supposed to be about hiding details that don't matter. > And in my opinion, this is one of those details. I think it depends on the context. > I've also seen code written where this sort of thing was taken to an > obscene degree where you'd have 10-30 layers all making the same > validity tests to ensure the data was really really good when it was > impossible to get down more than a layer or two and have it be bad. > Before you say that more tests are good, I cleaned up this mess and > was able to reduce 5 overlay regions (yes, 5!) on a pdp-11 fortran > monster due to systematically eliminating them (well, I ifdef'd them > out (we wrote a fortran preprocessor, but that's another story)). The > code went from something like 500k to 225k by removing the redundant > tests through all the layers. I know this is an extreme example, but > it does go to show that sometimes these tests can be rather > signficicant. I agree with what you are saying, and yes, it is an extreme example. I guess I was focused on the particular case of free(). I happy with the opinions I've received. Based on them, I seem to be in the minority of preferring `if (data) free(data);' in some cases. OTOH, our code base speaks differently than the email I've received -- `if (data) free(data);' seems to be used quite alot. I will probably continue to use it the way I have before -- to make it clear that there may or may not be memory to free at this point. Cheers, -- Jacques Vidrine / n@nectar.com / jvidrine@verio.net / nectar@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message