From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:37362) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RbZTR-0000LL-Mw for qemu-devel@nongnu.org; Fri, 16 Dec 2011 10:13:31 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RbZTM-0000WC-28 for qemu-devel@nongnu.org; Fri, 16 Dec 2011 10:13:25 -0500 Received: from mx1.redhat.com ([209.132.183.28]:65198) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RbZTL-0000W8-Nt for qemu-devel@nongnu.org; Fri, 16 Dec 2011 10:13:19 -0500 Message-ID: <4EEB600A.50803@redhat.com> Date: Fri, 16 Dec 2011 16:13:14 +0100 From: Paolo Bonzini MIME-Version: 1.0 References: <1324036918-2405-1-git-send-email-pbonzini@redhat.com> <1324036918-2405-2-git-send-email-pbonzini@redhat.com> <4EEB4DE2.2060805@codemonkey.ws> <4EEB4F0C.7050702@redhat.com> <4EEB5152.2010405@codemonkey.ws> <4EEB543C.5030104@redhat.com> <4EEB59CE.809@codemonkey.ws> <4EEB5A6D.4080705@redhat.com> <4EEB5C11.5040907@codemonkey.ws> <4EEB5DD4.50302@redhat.com> <4EEB5E52.7090204@codemonkey.ws> In-Reply-To: <4EEB5E52.7090204@codemonkey.ws> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 1/8] qapi: fix NULL pointer dereference List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: kwolf@redhat.com, qemu-devel@nongnu.org On 12/16/2011 04:05 PM, Anthony Liguori wrote: >> >> >>> What are the uses of null in qdev string properties? I know you can't >>> set a string to null since parse() doesn't have a null syntax. So we're >>> really just talking about an uninitialized state, right? >> >> Yes. No ROM BAR is an example of a NULL string property. > > So it's really filenames and backend names, right? Can we just treat > empty strings like NULL? I think all of the various bits handles both > the same way. The only case I can think of when it differs is serial numbers. An empty serial number is different from no serial number (which means do not expose one at all). However, DEFINE_PROP_STRING does not allow setting a default, and some device models rely on a NULL value as a default. I see two ways out: 1) add nullable strings; 2) merge without this patch, knowing qom-get is kind-of broken, and proceed adding a default to all DEFINE_PROP_STRING; this would be a merge nightmare for you. 3) merge without this patch, knowing it's kind-of broken, and later decide what to do. Let's do (3), and add nullable strings if the discussion stalls. Paolo