From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cooper Subject: Re: [PATCH] libxl: handle null lists in libxl_string_list_length Date: Fri, 27 Sep 2013 13:23:49 +0100 Message-ID: <524578D5.8060808@citrix.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Matthew Daley Cc: Boris Ostrovsky , Ian Campbell , "xen-devel@lists.xen.org" List-Id: xen-devel@lists.xenproject.org On 27/09/13 13:20, Matthew Daley wrote: > On Sat, Sep 28, 2013 at 12:08 AM, Boris Ostrovsky > wrote: >> ----- mattjd@gmail.com wrote: >> >>> After commit b0be2b12 ("libxl: fix libxl_string_list_length and its >>> only >>> caller") libxl_string_list_length no longer handles null (empty) >>> lists. Fix >>> so they are handled, returning length 0. >>> >>> While at it, remove the unneccessary undereferenced null pointer >>> check >> Are you sure this check should be removed? This routine can be called >> from anywhere (at least within libxl it seems) and one day someone will >> call it with NULL argument. >> >> I'd probably leave this check in. > I would argue that any such invocation would be an error by the caller > and should fail noisily, similar to how passing NULL into strlen > should not return 0. libxl_{string,key_value}_list_dispose similarly > assumes non-NULL pointers, FWIW. > > Ian C., do you have an opinion either way? > > - Matthew I would agree that any passing of NULL is a caller error. Possibly an explicit check and abort()? If it is going to be noisy, we should be nice and help out the debugger. ~Andrew