summaryrefslogtreecommitdiff
path: root/Documentation/git-clone.txt
diff options
context:
space:
mode:
authorLibravatar Jeff King <peff@peff.net>2012-10-18 06:00:12 -0400
committerLibravatar Junio C Hamano <gitster@pobox.com>2012-10-18 09:40:15 -0700
commit08ad56f3f0c1df8f75bac84bcef0d9d0c9b4d20f (patch)
treece27466c7455ee68fb1ac2b6f6d03367fcdb72bb /Documentation/git-clone.txt
parentGit 1.7.10.5 (diff)
downloadtgif-08ad56f3f0c1df8f75bac84bcef0d9d0c9b4d20f.tar.xz
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>
Diffstat (limited to 'Documentation/git-clone.txt')
0 files changed, 0 insertions, 0 deletions