Am 20.01.2010 12:09, schrieb Kirill A. Shutemov:
> On Wed, Jan 20, 2010 at 12:33 PM, Daniel P. Berrange
> <berra...@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 <quint...@redhat.com> wrote:
>>>> From: Kirill A. Shutemov <kir...@shutemov.name>
>>>>
>>>> CC block/vvfat.o
>>>> cc1: warnings being treated as errors
>>>> block/vvfat.c: In function 'commit_one_file':
>>>> block/vvfat.c:2259: error: ignoring return value of 'ftruncate', declared
>>>> with attribute warn_unused_result
>>>> make: *** [block/vvfat.o] Error 1
>>>> CC block/vvfat.o
>>>> In file included from /usr/include/stdio.h:912,
>>>> from ./qemu-common.h:19,
>>>> from block/vvfat.c:27:
>>>> In function 'snprintf',
>>>> inlined from 'init_directories' at block/vvfat.c:871,
>>>> inlined from 'vvfat_open' at block/vvfat.c:1068:
>>>> /usr/include/bits/stdio2.h:65: error: call to __builtin___snprintf_chk
>>>> will always overflow destination buffer
>>>> make: *** [block/vvfat.o] Error 1
>>>>
>>>> Signed-off-by: Kirill A. Shutemov <kir...@shutemov.name>
>>>> Signed-off-by: Juan Quintela <quint...@redhat.com>
>>>> ---
>>>> block/vvfat.c | 9 +++++++--
>>>> 1 files changed, 7 insertions(+), 2 deletions(-)
>>>>
>>>> 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,
>>>> {
>>>> direntry_t* entry=array_get_next(&(s->directory));
>>>> entry->attributes=0x28; /* archive | volume label */
>>>> - snprintf((char*)entry->name,11,"QEMU VVFAT");
>>>> + memcpy(entry->name,"QEMU VVF",8);
>>>> + memcpy(entry->extension,"AT ",3);
>>>> }
>>>
>>> Better to use
>>>
>>> memcpy(entry->name, "QEMU VVFAT", 11);
>>>
>>> memcpy() doesn't check bounds.
>>
>> 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.
Kevin
