Welcome to mirror list, hosted at ThFree Co, Russian Federation.

git.kernel.org/pub/scm/git/git.git - Unnamed repository; edit this file 'description' to name the repository.
summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorJeff King <peff@peff.net>2012-10-18 14:00:12 +0400
committerJunio C Hamano <gitster@pobox.com>2012-10-18 20:40:15 +0400
commit08ad56f3f0c1df8f75bac84bcef0d9d0c9b4d20f (patch)
treece27466c7455ee68fb1ac2b6f6d03367fcdb72bb /Makefile
parent785ee4960c3d334cbc2b17ab74d2cebdf1b4db64 (diff)
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 'Makefile')
0 files changed, 0 insertions, 0 deletions