From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S935917Ab3BOOwq (ORCPT ); Fri, 15 Feb 2013 09:52:46 -0500 Received: from userp1040.oracle.com ([156.151.31.81]:44096 "EHLO userp1040.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S935884Ab3BOOwp (ORCPT ); Fri, 15 Feb 2013 09:52:45 -0500 Date: Fri, 15 Feb 2013 17:52:26 +0300 From: Dan Carpenter To: Peter Huewe Cc: Rupesh Gujare , Greg Kroah-Hartman , devel@driverdev.osuosl.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 3/7 v2] staging/ozwpan: Fix NULL vs zero in ozeltbuf.c (sparse warning) Message-ID: <20130215145226.GI6853@mwanda> References: <20130215084517.GB6802@mwanda> <1360938148-19225-1-git-send-email-peterhuewe@gmx.de> <1360938148-19225-3-git-send-email-peterhuewe@gmx.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1360938148-19225-3-git-send-email-peterhuewe@gmx.de> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Feb 15, 2013 at 03:22:24PM +0100, Peter Huewe wrote: > This patch fixes the warning "Using plain integer as NULL pointer", > generated by sparse, by replacing the offending 0s with NULL. > > If the initialization with NULL was unnecessary (due to unconditional > assignment before first use) it was removed. > > Signed-off-by: Peter Huewe > --- > @@ -151,7 +151,7 @@ int oz_elt_stream_create(struct oz_elt_buf *buf, u8 id, int max_buf_count) > int oz_elt_stream_delete(struct oz_elt_buf *buf, u8 id) > { > struct list_head *e; > - struct oz_elt_stream *st; > + struct oz_elt_stream *st = NULL; > oz_trace("oz_elt_stream_delete(0x%x)\n", id); > spin_lock_bh(&buf->lock); > e = buf->stream_list.next; You changed the code here. The original code would crash if buf->stream_list was empty. I don't if that can happen, but I still consider it a bug fix. Good job, but next time you mention it in the changelog. You've fixed a couple of these uninitialized variable bugs recently. Is this is a clang warning? GCC doesn't catch it. regards, dan carpenter