From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1NXZnH-0000yi-1u
	for qemu-devel@nongnu.org; Wed, 20 Jan 2010 07:36:19 -0500
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1NXZnG-0000xq-BL
	for qemu-devel@nongnu.org; Wed, 20 Jan 2010 07:36:18 -0500
Received: from [199.232.76.173] (port=44309 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1NXZnG-0000xf-7f
	for qemu-devel@nongnu.org; Wed, 20 Jan 2010 07:36:18 -0500
Received: from ey-out-1920.google.com ([74.125.78.144]:50168)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <kirill@shutemov.name>) id 1NXZnF-0002I1-SP
	for qemu-devel@nongnu.org; Wed, 20 Jan 2010 07:36:18 -0500
Received: by ey-out-1920.google.com with SMTP id 4so1088275eyg.2
	for <qemu-devel@nongnu.org>; Wed, 20 Jan 2010 04:36:16 -0800 (PST)
MIME-Version: 1.0
In-Reply-To: <m3y6jt6kgb.fsf@blackfin.pond.sub.org>
References: <cover.1263944807.git.quintela@redhat.com>
	<85e877202ec86dac15d392f5e88d5b5d76e3b02f.1263944807.git.quintela@redhat.com>
	<cc557aab1001192219g423baff2ncf905a33c9a1d56a@mail.gmail.com>
	<20100120103324.GA17856@redhat.com>
	<cc557aab1001200309l738f5aefsdf7da77b25e6e416@mail.gmail.com>
	<4B56ECBC.40804@redhat.com> <m3y6jt6kgb.fsf@blackfin.pond.sub.org>
Date: Wed, 20 Jan 2010 14:36:15 +0200
Message-ID: <cc557aab1001200436y44fc74d7n4f97d7d46fbefa33@mail.gmail.com>
Subject: Re: [Qemu-devel] Re: [PATCH 07/17] block/vvfat.c: fix warnings with
	_FORTIFY_SOURCE
From: "Kirill A. Shutemov" <kirill@shutemov.name>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Markus Armbruster <armbru@redhat.com>
Cc: Kevin Wolf <kwolf@redhat.com>, qemu-devel@nongnu.org, Juan Quintela <quintela@redhat.com>

On Wed, Jan 20, 2010 at 2:15 PM, Markus Armbruster <armbru@redhat.com> wrot=
e:
> Kevin Wolf <kwolf@redhat.com> writes:
>
>> Am 20.01.2010 12:09, schrieb Kirill A. Shutemov:
>>> On Wed, Jan 20, 2010 at 12:33 PM, Daniel P. Berrange
>>> <berrange@redhat.com> wrote:
>>>> On Wed, Jan 20, 2010 at 08:19:26AM +0200, Kirill A. Shutemov wrote:
>>>>> On Wed, Jan 20, 2010 at 1:56 AM, Juan Quintela <quintela@redhat.com> =
wrote:
> [...]
>>>>>> diff --git a/block/vvfat.c b/block/vvfat.c
>>>>>> index 063f731..df957e5 100644
>>>>>> --- a/block/vvfat.c
>>>>>> +++ b/block/vvfat.c
>>>>>> @@ -868,7 +868,8 @@ static int init_directories(BDRVVVFATState* s,
>>>>>> =C2=A0 =C2=A0 {
>>>>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0direntry_t* entry=3Darray_get_next(&(s->d=
irectory));
>>>>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0entry->attributes=3D0x28; /* archive | vo=
lume label */
>>>>>> - =C2=A0 =C2=A0 =C2=A0 snprintf((char*)entry->name,11,"QEMU VVFAT");
>>>>>> + =C2=A0 =C2=A0 =C2=A0 memcpy(entry->name,"QEMU VVF",8);
>>>>>> + =C2=A0 =C2=A0 =C2=A0 memcpy(entry->extension,"AT ",3);
>>>>>> =C2=A0 =C2=A0 }
>>>>>
>>>>> Better to use
>>>>>
>>>>> memcpy(entry->name, "QEMU VVFAT", 11);
>>>>>
>>>>> memcpy() doesn't check bounds.
>
> No, this is evil, and may well be flagged by static analysis tools.

If so, the tool is stupid.

>>>> It doesn't *currently* check bounds.
>>>
>>> No. memcpy() will never check bounds. It's totaly different from strcpy=
,
>>> http://gcc.gnu.org/ml/gcc-patches/2009-06/msg00419.html
>>
>> Regardless if deliberately overflowing the buffer works or doesn't
>> making it explicit is better. Someone might reorder the struct or add
>> new fields in between (okay, unlikely in this case, but still) and
>> you'll overflow into fields you never wanted to touch.
>
> Moreover, compilers are free to put padding between members name and
> extension.

No, compiler can't add anything between. 'char' is always byte-aligned.