Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S262254AbTGKOSJ (ORCPT ); Fri, 11 Jul 2003 10:18:09 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261944AbTGKOQq (ORCPT ); Fri, 11 Jul 2003 10:16:46 -0400 Received: from zeke.inet.com ([199.171.211.198]:1169 "EHLO zeke.inet.com") by vger.kernel.org with ESMTP id S261985AbTGKOPB (ORCPT ); Fri, 11 Jul 2003 10:15:01 -0400 Message-ID: <3F0EC9C9.4090307@inet.com> Date: Fri, 11 Jul 2003 09:29:29 -0500 From: Eli Carter User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alan Stern CC: linux-kernel@vger.kernel.org Subject: Re: Style question: Should one check for NULL pointers? References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1777 Lines: 44 Alan Stern wrote: > On Thu, 10 Jul 2003, Eli Carter wrote: > > >>Alan Stern wrote: >>[snip] >> >>>Ultimately this comes down to a question of style and taste. This >>>particular issue is not addressed in Documentation/CodingStyle so I'm >>>raising it here. My personal preference is for code that means what it >>>says; if a pointer is checked it should be because there is a genuine >>>possibility that the pointer _is_ NULL. I see no reason for pure >>>paranoia, particularly if it's not commented as such. >>> >>>Comments, anyone? >> >>BUG_ON() perhaps? > > > Not really needed, since a segfault will produce almost as much > information as a BUG_ON(). Certainly it will produce enough to let a > developer know that the pointer was NULL. Your first message said, "I see no reason for pure paranoia, particularly if it's not commented as such." A BUG_ON() call makes it clear that the condition should never happen. Dereferencing a NULL leaves the question of whether NULL is an unhandled case or invalid input. BUG_ON() is an explicit paranoia check, and with a bit of preprocessing magic, you could compile out all of those checks. So it documents invalid input conditions, allows you to eliminate the checks in the name of speed or your personal preference, or use them to help with debugging/testing. Eli --------------------. "If it ain't broke now, Eli Carter \ it will be soon." -- crypto-gram eli.carter(a)inet.com `------------------------------------------------- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/