]> git.ipfire.org Git - thirdparty/git.git/commit - strbuf.c
strbuf: always return a non-NULL value from strbuf_detach
authorJeff King <peff@peff.net>
Thu, 18 Oct 2012 10:00:12 +0000 (06:00 -0400)
committerJunio C Hamano <gitster@pobox.com>
Thu, 18 Oct 2012 16:40:15 +0000 (09:40 -0700)
commit08ad56f3f0c1df8f75bac84bcef0d9d0c9b4d20f
treece27466c7455ee68fb1ac2b6f6d03367fcdb72bb
parent785ee4960c3d334cbc2b17ab74d2cebdf1b4db64
strbuf: always return a non-NULL value from strbuf_detach

The current behavior is to return NULL when strbuf did not
actually allocate a string. This can be quite surprising to
callers, though, who may feed the strbuf from arbitrary data
and expect to always get a valid value.

In most cases, it does not make a difference because calling
any strbuf function will cause an allocation (even if the
function ends up not inserting any data). But if the code is
structured like:

  struct strbuf buf = STRBUF_INIT;
  if (some_condition)
  strbuf_addstr(&buf, some_string);
  return strbuf_detach(&buf, NULL);

then you may or may not return NULL, depending on the
condition. This can cause us to segfault in http-push
(when fed an empty URL) and in http-backend (when an empty
parameter like "foo=bar&&" is in the $QUERY_STRING).

This patch forces strbuf_detach to allocate an empty
NUL-terminated string when it is called on a strbuf that has
not been allocated.

I investigated all call-sites of strbuf_detach. The majority
are either not affected by the change (because they call a
strbuf_* function unconditionally), or can handle the empty
string just as easily as NULL.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
strbuf.c