[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 1/8] qapi: fix NULL pointer dereference

From: Anthony Liguori
Subject: Re: [Qemu-devel] [PATCH 1/8] qapi: fix NULL pointer dereference
Date: Fri, 16 Dec 2011 09:23:36 -0600
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20110831 Lightning/1.0b2 Thunderbird/3.1.13

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 

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.


Anthony Liguori

Let's do (3), and add nullable strings if the discussion stalls.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]