Re: [GSoC][RFC][PATCH 2/2] STRBUF_INIT_CONST: Adapting strbuf_* functions

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Robear Selwans <rwagih.rw@xxxxxxxxx> writes:

> On Wed, Feb 19, 2020 at 5:13 AM Junio C Hamano <gitster@xxxxxxxxx> 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.




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux