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/