From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:43794) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RbZdS-0002wb-Da for qemu-devel@nongnu.org; Fri, 16 Dec 2011 10:23:51 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RbZdO-0002m1-Bm for qemu-devel@nongnu.org; Fri, 16 Dec 2011 10:23:46 -0500 Received: from mail-iy0-f173.google.com ([209.85.210.173]:46647) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RbZdO-0002lv-8E for qemu-devel@nongnu.org; Fri, 16 Dec 2011 10:23:42 -0500 Received: by iagj37 with SMTP id j37so5123328iag.4 for ; Fri, 16 Dec 2011 07:23:41 -0800 (PST) Message-ID: <4EEB6278.6070401@codemonkey.ws> Date: Fri, 16 Dec 2011 09:23:36 -0600 From: Anthony Liguori 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> <4EEB600A.50803@redhat.com> In-Reply-To: <4EEB600A.50803@redhat.com> 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: Paolo Bonzini Cc: kwolf@redhat.com, qemu-devel@nongnu.org On 12/16/2011 09:13 AM, Paolo Bonzini wrote: > 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. I thrive on pain it seems :-) > 3) merge without this patch, knowing it's kind-of broken, and > later decide what to do. Ok. I think nullable strings are not a good idea simply because it means that a property can have a state that cannot be set. Long term, I want to be able to do something like dump the current device graph to a config file, and then use that config file to recreate the same machine again. A nullable property without a null representation would not allow this. Regards, Anthony Liguori > Let's do (3), and add nullable strings if the discussion stalls. > > Paolo >