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

[Gleb Natapov <gleb@redhat.com>]

On Wed, Jan 20, 2010 at 02:03:04PM +0100, Markus Armbruster wrote:
> "Kirill A. Shutemov" <kirill@shutemov.name> writes:
> 
> > On Wed, Jan 20, 2010 at 2:15 PM, Markus Armbruster <armbru@redhat.com> wrote:
> >> 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,
> >>>>>>>     {
> >>>>>>>        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.
> 
To be fair this structure is packed, but this is not the reason to write
stupid code of course.
 
--
			Gleb.