From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:43197)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <p.fedin@samsung.com>) id 1ZKS23-00010v-By
	for qemu-devel@nongnu.org; Wed, 29 Jul 2015 10:08:36 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <p.fedin@samsung.com>) id 1ZKS1w-0003cM-S7
	for qemu-devel@nongnu.org; Wed, 29 Jul 2015 10:08:31 -0400
Received: from mailout4.w1.samsung.com ([210.118.77.14]:35428)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <p.fedin@samsung.com>) id 1ZKS1w-0003bK-L3
	for qemu-devel@nongnu.org; Wed, 29 Jul 2015 10:08:24 -0400
Received: from eucpsbgm1.samsung.com (unknown [203.254.199.244])
	by mailout4.w1.samsung.com
	(Oracle Communications Messaging Server 7.0.5.31.0 64bit (built May 5
	2014)) with ESMTP id <0NS900LH45XW7280@mailout4.w1.samsung.com> for
	qemu-devel@nongnu.org; Wed, 29 Jul 2015 15:08:20 +0100 (BST)
From: Pavel Fedin <p.fedin@samsung.com>
References: <019001d0c9fd$d3268410$79738c30$@samsung.com>
	<20150729133459.GE16847@redhat.com>
In-reply-to: <20150729133459.GE16847@redhat.com>
Date: Wed, 29 Jul 2015 17:08:18 +0300
Message-id: <01b801d0ca08$05e335b0$11a9a110$@samsung.com>
MIME-version: 1.0
Content-type: text/plain; charset=UTF-8
Content-transfer-encoding: quoted-printable
Content-language: ru
Subject: Re: [Qemu-devel] [PATCH] Do not use slow [*] expansion for
	GPIO	creation
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: "'Daniel P. Berrange'" <berrange@redhat.com>
Cc: 'Paolo Bonzini' <pbonzini@redhat.com>, 'QEMU Developers' <qemu-devel@nongnu.org>, =?UTF-8?Q?'Andreas_F=C3=A4rber'?= <afaerber@suse.de>, 'Markus Armbruster' <armbru@redhat.com>

 Hello!

> > +    l =3D strlen(name);
> > +    propname =3D g_malloc(l + 13); /* 10 characters for UINT_MAX =
plus "[]" */
> > +    memcpy(propname, name, l);
>=20
> Please don't do manual string length calculations in combination with
> unbounded sprintf calls. It is a recipe for future security bugs.

[skip]

> >      for (i =3D gpio_list->num_in; i < gpio_list->num_in + n; i++) {
> > +        g_sprintf(&propname[l], "[%u]", i);
>=20
> Replace this with
>=20
>     gchar *propname =3D g_strdup_printf("%s[%u]", name, i)
>=20
> >          object_property_add_child(OBJECT(dev), propname,
> >                                    OBJECT(gpio_list->in[i]), =
&error_abort);
>=20
>     g_free(propname);

 IMHO it's not really good because of repeating allocation-free. This is =
not VERY slow, but still slower than it could be (imagine that this =
repeats ~1000 times).
 I have a better idea instead. What if instead:

propname =3D g_malloc(l + 13); /* 10 characters for UINT_MAX plus "[]" =
*/

 i do:

propname =3D g_strdup_printf("%s[%u]", name, -1)

 ? This will automatically give me a buffer to fit in the largest =
possible integer.

Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia