Date: Mon, 18 Dec 2000 12:27:55 -0700 From: Warner Losh <imp@village.org> To: "Jacques A. Vidrine" <n@nectar.com> Cc: hackers@FreeBSD.ORG Subject: Re: Why not another style thread? (was Re: cvs commit: src/lib/libc/gen getgrent.c) Message-ID: <200012181927.MAA93102@harmony.village.org> In-Reply-To: Your message of "Mon, 18 Dec 2000 13:11:12 CST." <20001218131112.B65143@hamlet.nectar.com> References: <20001218131112.B65143@hamlet.nectar.com> <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>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <20001218131112.B65143@hamlet.nectar.com> "Jacques A. Vidrine" writes: : Ever notice that you tend to send more email when you should be studying : for a final? That's why Style(9) wars break out this time of year. :-) : /* 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. Depends on the reader. case 2 to me says "free the memory, if there's any to free". This encapsulates case 1 better than having it be explicit. : 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. The if (data) free(data); is the dusty deck problem, also known as the dead hand of the past problem. Back before ANSI-C (in the mid 1980's), some frees would core dump on free(NULL), while others would accept it. ANSI-C dictated that it should be accepted and nothing should happen. All code wasn't changed over night. This is the same reason that we have the uglification of __P() in our tree too. Compilers were slow to adpot ANSI-C (no called iso-c or c89) so allowances needed to be made for the multiple environments the code would work in. Now that K&R is totally dead, except maybe on Bruce's machines, the need for it no longer exists. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200012181927.MAA93102>