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

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

 



On Tue, Feb 18, 2020 at 10:46 PM Junio C Hamano <gitster@xxxxxxxxx> wrote:
> Abhishek Kumar <abhishekkumar8222@xxxxxxxxx> writes:
> >> STRBUF_INIT_CONST: a new way to initialize strbuf
> > Use imperative mood and be more specific in the commit title -
> > `strbuf: Teach strbuf to initialize immutable strings`
> s/T/t/;
I don't get what you mean by that.

> Also, isn't "if (sb->alloc < sb->len)" too loose a check for the new
> feature?  AFAICS in 1/2, a strbuf that is still borrowing a const
> string always has sb->alloc==0.  Other instances of strbuf that
> happens to satisify the above condition, e.g. (sb->len == 5 &&
> sb->alloc == 1), is an error.  If we are to check the condition
> about sb->len, shouldn't we diagnose such a case as an error, no?
AFAIK after reading the documentation for `strbuf`, there is no other
case where `sb->len > sb->alloc` as `alloc` needs to always be more
than `len`. I'd like to be corrected if mistaken, though.

> As Peff, I am a bit hesitant about leaving a strbuf that hasn't been
> made mutable around, though.
Yeah, I started to get that when I read Peff's reply. I think I'll go with
the approach that Peff suggested, where the constant string is
copied to a stack array and so is made mutable to a degree. Since
this is a different way, I guess I'll make that from scratch instead of
editing the existing one.



[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