Rob, Sorry, you read it right.
This code was recently uploaded and the changes were in the repo: https://github.com/JoeDog/siege Merging your changes with it, the block is shown below. The if-check is gone because it segfaulted if the post data was read from a file that contained a null byte. void url_set_postdata(URL this, char *postdata, size_t postlen) { this->postlen = postlen; this->postdata = xmalloc(this->postlen+1); memcpy(this->postdata, postdata, this->postlen); this->postdata[this->postlen] = '\0'; return; } On Tue, Jul 7, 2015 at 11:40 PM, Rob Browning <r...@defaultvalue.org> wrote: > 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 > >
