From: Igor Mammedov <imammedo@redhat.com>
To: "Andreas Färber" <afaerber@suse.de>
Cc: aliguori@us.ibm.com, Igor Mitsyanko <i.mitsyanko@samsung.com>,
alexander_barabash@mentor.com,
Markus Armbruster <armbru@redhat.com>,
qemu-devel@nongnu.org, Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: [Qemu-devel] [PATCH qom-next] qom: make object cast assert if NULL object is passed as argument
Date: Mon, 04 Jun 2012 15:14:58 +0200 [thread overview]
Message-ID: <4FCCB4D2.7070607@redhat.com> (raw)
In-Reply-To: <4FC8BDC6.70804@suse.de>
On 06/01/2012 03:04 PM, Andreas Färber wrote:
> Am 01.06.2012 13:18, schrieb Markus Armbruster:
>> Andreas Färber<afaerber@suse.de> writes:
>>
>>> Am 31.05.2012 13:17, schrieb Igor Mammedov:
>>>> On 05/31/2012 12:16 PM, Paolo Bonzini wrote:
>>>>> Il 31/05/2012 10:30, Markus Armbruster ha scritto:
>>>>>>>> Makes much sense, but maybe it should be done in OBJECT() cast? Assert
>>>>>>>> when we do OBJECT(NULL).
>>>>>> In my opinion, OBJECT(p) where p is a null pointer is perfectly valid
>>>>>> and should yield a null pointer.
>>>>>
>>>>> Perhaps object_dynamic_cast and object_dynamic_cast_assert should do the
>>>>> same?
>>>>>
>>>>
>>>> or better object_dynamic_cast should return NULL if obj is NULL,
>>>> after all it's expected that it may return NULL
>>>
>>> That's what I was suggesting: I think that we should define "NULL is not
>>> of type TYPE_FOO" and thus have the ..._is_... functions return false,
>>> and have the ..._cast_assert assert.
>>
>> Is it?
>
> See http://www.mail-archive.com/qemu-devel@nongnu.org/msg113922.html
>
>> Igor: object_dynamic_cast should return NULL if obj is NULL,
>>
>> You: have the ..._cast_assert assert [on null argument, I presume]
>>
>> Doesn't sound like the same suggestion to me :)
>
> I'll let you to your opinion. :) However, my opinion is that
> object_dynamic_cast_assert() should assert (its name should be program),
> not segfault, and that
> object_dynamic_cast()/object_is_type()/type_is_ancestor() should not
> assert but return false / NULL. So as to the effects and usability that
> pretty much aligns with Igor M., no?
If we decide that object_dynamic_cast() should not assert but rather return NULL
the this block in it will be incorrect in to places:
if (object_is_type(obj, type_interface)) {
assert(!obj->interfaces); <== could be replaced with return NULL
obj = INTERFACE(obj)->obj; <== calls OBJECT_CHECK() -> object_dynamic_cast_assert ()
...
[snip]
maybe there should be INTERFACE_CHECK and INTERFACE macros calling ..._assert and non assert variants respectively?
>
>> If I understood you correctly: what do such assertions buy us other than
>> silliness like
>>
>> p ? some_cast(p) : NULL
>>
>> ?
>
> Nack. The point is that currently deployed MY_TYPE(x) should assert
> (because nobody expects it to return NULL) and he who does want to
> handle NULL can use object_dynamic_cast(p). There's no real change to
> what we have except that an error case that was unhandled now is handled.
>
>>> So I still think this patch is correct. It could be accompanied by
>>> further patches adding error handling in the remaining functions.
>>
>> I'm not convinced.
>
> Shed any light?
>
> Andreas
>
--
-----
Igor
next prev parent reply other threads:[~2012-06-04 13:15 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1338394747-17427-1-git-send-email-imammedo@redhat.com>
[not found] ` <4FC6533C.3010207@samsung.com>
[not found] ` <m3k3zswy4r.fsf@blackfin.pond.sub.org>
[not found] ` <4FC744FE.3030203@redhat.com>
[not found] ` <4FC7533B.2060102@redhat.com>
2012-06-01 9:52 ` [Qemu-devel] [PATCH qom-next] qom: make object cast assert if NULL object is passed as argument Andreas Färber
2012-06-01 11:18 ` Markus Armbruster
2012-06-01 13:04 ` Andreas Färber
2012-06-04 7:39 ` Markus Armbruster
2012-06-04 13:14 ` Igor Mammedov [this message]
2012-06-01 9:57 ` Andreas Färber
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4FCCB4D2.7070607@redhat.com \
--to=imammedo@redhat.com \
--cc=afaerber@suse.de \
--cc=alexander_barabash@mentor.com \
--cc=aliguori@us.ibm.com \
--cc=armbru@redhat.com \
--cc=i.mitsyanko@samsung.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.