qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Re: [PATCH 07/17] block/vvfat.c: fix warnings with _FOR


From: Markus Armbruster
Subject: Re: [Qemu-devel] Re: [PATCH 07/17] block/vvfat.c: fix warnings with _FORTIFY_SOURCE
Date: Wed, 20 Jan 2010 14:03:04 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux)

"Kirill A. Shutemov" <address@hidden> writes:

> On Wed, Jan 20, 2010 at 2:15 PM, Markus Armbruster <address@hidden> wrote:
>> Kevin Wolf <address@hidden> writes:
>>
>>> Am 20.01.2010 12:09, schrieb Kirill A. Shutemov:
>>>> On Wed, Jan 20, 2010 at 12:33 PM, Daniel P. Berrange
>>>> <address@hidden> 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 <address@hidden> 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,
>>>>>>>     {
>>>>>>>        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.
>>
>> 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.

You got some reading to do then.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]