Both of you Davids are indeed completely right. Even more since the
next command in the patch after memcpy zeroes that byte.

This is how it's meant to be:

+    content_data = talloc_size (ctx, part_content->len+1);
+    memcpy (content_data, (char *)part_content->data, part_content->len);
+    content_data[part_content->len] = 0;

Should I submit a fixed patch?

Mea culpa,
    Gregor


* David Edmondson <dme at dme.org> [Do Apr 01 13:50:54 +0200 2010]
> On Thu, 01 Apr 2010 08:40:37 -0300, David Bremner <david at tethera.net> 
> wrote:
> > On Thu, 04 Mar 2010 11:49:48 +0100, Gregor Hoffleit <gregor at hoffleit.de> 
> > wrote:
> > > In format_part_json, part_content->data is not a null terminated
> > > string.
> > 
> > I'd like to see this bug fixed,
> 
> +1.
> 
> > and the patch is pretty small, but...
> > 
> > > Instead, we have to use part_content->len.
> > > +    content_data = talloc_size (ctx, part_content->len+1);
> > > +    memcpy (content_data, (char *)part_content->data, 
> > > part_content->len+1);
> > 
> > Can anyone explain why we copy (what seems to me to be) one extra byte
> > here?  In principle reading outside our allocated memory could cause
> > problems; at minimum it makes a false positive for a memory checker like
> > valgrind.
> 
> Agreed. It looks as though this should copy only part_content->len bytes.
> 
> dme.

-- 
Gregor Hoffleit <gregor.hoffleit at mediasupervision.de>
Media Supervision Software Consulting GmbH
Georg-Friedrich-Haendel-Str. 13, 69214 Eppelheim/Heidelberg
Tel: +49 6221 705079-22  /  Fax: +49 6221 705079-80
Amtsgericht Mannheim, HRB 336821, Gesch?ftsf?hrer Reinhard Kratzke
http://www.mediasupervision.de/

Reply via email to