qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Krzysztof Kozlowski <krzk@kernel.org>
To: Eduardo Habkost <ehabkost@redhat.com>
Cc: "Kevin Wolf" <kwolf@redhat.com>,
	"Paolo Bonzini" <pbonzini@redhat.com>,
	"Max Reitz" <mreitz@redhat.com>,
	"Markus Armbruster" <armbru@redhat.com>,
	"Marc-André Lureau" <marcandre.lureau@redhat.com>,
	"Alex Williamson" <alex.williamson@redhat.com>,
	qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH] qdev: Constify data pointed by few arguments and local variables
Date: Wed, 8 Mar 2017 21:34:19 +0200	[thread overview]
Message-ID: <20170308193419.qj7xfour4xql4xzi@kozik-lap> (raw)
In-Reply-To: <20170308192201.GI4694@thinpad.lan.raisama.net>

On Wed, Mar 08, 2017 at 04:22:01PM -0300, Eduardo Habkost wrote:
> On Wed, Mar 08, 2017 at 09:06:06PM +0200, Krzysztof Kozlowski wrote:
> > > > The object_property_set_str() takes data as pointer to const. If data
> > > > ends up as being non-const, then this is the mistake -
> > > > object_property_set_str().
> > > 
> > > I don't see the mistake. The whole purpose of:
> > >   qdev_prop_set_chr(dev, "some-field", v)
> > > is to end up doing this assignment internally:
> > >   dev->some_field = v;
> > > and on most (or all?) cases dev->some_field is not a const
> > > pointer. The details are hidden behind the
> > > object_property_set_str() call.
> > 
> > If that would be the case, the object_property_set_str() cannot take a
> > pinter to const. Not only because of the safety and logic but also C
> > will prohibit it without a case.
> > 
> > 	const char *c = "foo bar";
> > 	char *v = c;
> > 
> > 	/home/dev/qemu/qemu/qobject/qstring.c:67:15: error: initialization discards ‘const’ qualifier from pointer target type [-Werror=discarded-qualifiers]
> > 	     char *v = c;
> >                ^
> 
> The 'value' parameter to object_property_set_str() is const, and
> that's correct. But the set_chr() setter will take care of the
> 'dev->some_field = value' part.

In current implementation (v2.8.0-2132-gb64842dee42d) the
only thing qdev_prop_set_chr() does is to call
object_property_set_str() for value->label.

So the flow is:
    qdev_prop_set_chr(char *value)
        const char *l = value->label
        object_property_set_str(const char *l)
            dev->some_field = copy_of(l);

The only non-const part of the flow is the first call. All of others are
const.

Of course the implementation might change and maybe that is the
intention/plan - the qdev_prop_set_chr() should not commit to the caller
that it will not store the value itself.

Then I understand it.

However if there are no such plans, then in current implementation the
qdev_prop_set_chr() does not store any part of the 'value' itself but
only a copy of it through object_property_set_str(). Thus it can provide
this hint to the caller: I will not store the 'value' directly so I am
taking pointer to const.

Anyway, this is a trivial, boring and correctness-like change. :) Not worth
all the talks so I do not mind resending without this (and others which
were disapproved).

Best regards,
Krzysztof

  reply	other threads:[~2017-03-08 19:34 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-05 21:46 [Qemu-devel] [PATCH] qdev: Constify data pointed by few arguments and local variables Krzysztof Kozlowski
2017-03-06 12:09 ` Eduardo Habkost
2017-03-06 12:57   ` Paolo Bonzini
2017-03-08 16:22   ` Krzysztof Kozlowski
2017-03-08 18:57     ` Eduardo Habkost
2017-03-08 19:06       ` Krzysztof Kozlowski
2017-03-08 19:22         ` Eduardo Habkost
2017-03-08 19:34           ` Krzysztof Kozlowski [this message]
2017-03-08 19:53             ` Eduardo Habkost

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=20170308193419.qj7xfour4xql4xzi@kozik-lap \
    --to=krzk@kernel.org \
    --cc=alex.williamson@redhat.com \
    --cc=armbru@redhat.com \
    --cc=ehabkost@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=marcandre.lureau@redhat.com \
    --cc=mreitz@redhat.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).