From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([208.118.235.92]:35686)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <peter.maydell@linaro.org>) id 1ScQGU-0008Ix-J7
	for qemu-devel@nongnu.org; Wed, 06 Jun 2012 20:07:51 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <peter.maydell@linaro.org>) id 1ScQGS-0000Xy-SV
	for qemu-devel@nongnu.org; Wed, 06 Jun 2012 20:07:50 -0400
Received: from mail-bk0-f45.google.com ([209.85.214.45]:36833)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <peter.maydell@linaro.org>) id 1ScQGS-0000Xm-Ly
	for qemu-devel@nongnu.org; Wed, 06 Jun 2012 20:07:48 -0400
Received: by bkwj10 with SMTP id j10so25590bkw.4
	for <qemu-devel@nongnu.org>; Wed, 06 Jun 2012 17:07:46 -0700 (PDT)
MIME-Version: 1.0
In-Reply-To: <m37gvkd2gb.fsf@blackfin.pond.sub.org>
References: <1338900668-6093-1-git-send-email-armbru@redhat.com>
	<1338900668-6093-3-git-send-email-armbru@redhat.com>
	<CAFEAcA_7Rmr5WGTnRb=tH-b0g-oHkMKa3fT4xoL8Nxy2EsY_wg@mail.gmail.com>
	<m37gvkd2gb.fsf@blackfin.pond.sub.org>
Date: Thu, 7 Jun 2012 01:07:45 +0100
Message-ID: <CAFEAcA85CHTc_gioLZ-2Wxiko7Qutjia2nHLPgs2kpYLXR-PCw@mail.gmail.com>
From: Peter Maydell <peter.maydell@linaro.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [Qemu-devel] [PATCH 2/2] xen: Don't peek behind the
 BlockDriverState abstraction
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: Markus Armbruster <armbru@redhat.com>
Cc: kwolf@redhat.com, qemu-devel@nongnu.org, stefano.stabellini@eu.citrix.com

On 6 June 2012 13:55, Markus Armbruster <armbru@redhat.com> wrote:
> Peter Maydell <peter.maydell@linaro.org> writes:
>
>> On 5 June 2012 13:51, Markus Armbruster <armbru@redhat.com> wrote:
>>> @@ -554,6 +553,7 @@ static int blk_init(struct XenDevice *xendev)
>>> =C2=A0{
>>> =C2=A0 =C2=A0 struct XenBlkDev *blkdev =3D container_of(xendev, struct =
XenBlkDev, xendev);
>>> =C2=A0 =C2=A0 int index, qflags, info =3D 0;
>>> + =C2=A0 =C2=A0char fmt_name[128];
>>
>> Fixed length array with a hardcoded magic number size ?
>> If the block layer guarantees that format names are going to be
>> less than 128 bytes it ought to provide a suitable #define for
>> people to set array sizes to...
>
> Maybe it should, but it doesn't. =C2=A0Does it really matter in this
> particular case? =C2=A0If somebody insists on giving his driver a name lo=
nger
> than 127 characters, we'll silently log it truncated, that's all.

I think it matters in the general case, yours is just the first
usage of this API which has caught my attention. We should fix
the API before adding more uses of it (at the moment it seems to
be only used in two places).

Alternatively, we could have the function return a const char* rather
than taking a buffer to be filled in.

-- PMM