From: Junio C Hamano <gitster@pobox.com>
To: Robear Selwans <rwagih.rw@gmail.com>
Cc: "Abhishek Kumar" <abhishekkumar8222@gmail.com>,
git@vger.kernel.org, "René Scharfe" <l.s.r@web.de>,
"Nguyễn Thái Ngọc Duy" <pclouds@gmail.com>,
"Jeff King" <peff@peff.net>,
"Pratik Karki" <predatoramigo@gmail.com>
Subject: Re: [GSoC][RFC][PATCH 2/2] STRBUF_INIT_CONST: Adapting strbuf_* functions
Date: Wed, 19 Feb 2020 02:44:50 -0800 [thread overview]
Message-ID: <xmqqmu9ehn4t.fsf@gitster-ct.c.googlers.com> (raw)
In-Reply-To: <CALH1-XoXdpAxYj7r1ouc-v4KrVuYDocBFFC++7eFiRwdHFxmUA@mail.gmail.com> (Robear Selwans's message of "Wed, 19 Feb 2020 06:34:19 +0200")
Robear Selwans <rwagih.rw@gmail.com> writes:
> On Wed, Feb 19, 2020 at 5:13 AM Junio C Hamano <gitster@pobox.com> wrote:
>>
>> Yes, but the case that matters to _your_ use is sb->alloc == 0. You
>> do not want to let a broken strbuf (presumably broken by changes
>> other than your own) to pass, when you can detect it. And for that,
>> paying attention to sb->len _might_ make sense, but then the check
>> won't be
>>
>> if (sb->alloc < sb->len)
>> make it mutable;
>>
>> you'd rather be writing something like
>>
>> if (!sb->alloc)
>> make it mutable;
>> else if (sb->alloc < sb->len)
>> BUG("somebody fed a corrupt strbuf to me");
>
> Ooh so what you meant, is that corrupt `strbuf`s need to be
> anticipated even if they
> don't make much sense. Smart.
I don't know if that is smart, but the point is that sb->alloc is
the only thing you need to care about if you want to see if the
strbuf is borrowing from a const string, and it does not make much
sense not to catch a corruption, _if_ you are to check the value of
sb->len as well.
next prev parent reply other threads:[~2020-02-19 10:44 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-18 9:30 [GSoC][RFC][PATCH 2/2] STRBUF_INIT_CONST: Adapting strbuf_* functions Abhishek Kumar
2020-02-18 14:42 ` Robear Selwans
2020-02-18 20:46 ` Junio C Hamano
2020-02-19 1:43 ` Robear Selwans
2020-02-19 2:05 ` Jeff King
2020-02-19 3:13 ` Junio C Hamano
2020-02-19 4:34 ` Robear Selwans
2020-02-19 10:44 ` Junio C Hamano [this message]
-- strict thread matches above, loose matches on Subject: below --
2020-02-18 4:18 [GSoC][RFC][PATCH 0/2] STRBUF_INIT_CONST Cover Robear Selwans
2020-02-18 4:18 ` [GSoC][RFC][PATCH 2/2] STRBUF_INIT_CONST: Adapting strbuf_* functions Robear Selwans
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqqmu9ehn4t.fsf@gitster-ct.c.googlers.com \
--to=gitster@pobox.com \
--cc=abhishekkumar8222@gmail.com \
--cc=git@vger.kernel.org \
--cc=l.s.r@web.de \
--cc=pclouds@gmail.com \
--cc=peff@peff.net \
--cc=predatoramigo@gmail.com \
--cc=rwagih.rw@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.