Jeff Fulmer <j...@joedog.org> writes: > If we do it like that, aren't we whacking the last character of content?
Hmm, assuming I'm not misreading, perhaps not? Since for a length of say 1 it'll be "setting this->postdata[1] = 0", and given zero indexing, that'll be assigning 0 to the second character in the array. I believe the problem before was just that it was attempting to set an unallocated character to 0 (just off the end of the allocated area). Oh, and now that I look again, if this->postdata might already point to a dynamically allocated string that it owns, then I suspect there may be a memory leak. And if the reason for postlen is to either be more efficient, or to allow the possibility of not copying all of postdata, then the strlen(postdata) may be undesirable. Otherwise, perhaps postlen itself is redundant. If so, and if xstrdup() in lib/ does what I imagine, then that may provide a simpler solution. Hope this helps. -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
