Re: [PATCH] strbuf.c: optimize program logic

From: Junio C Hamano <gitster@pobox.com>
Date: Jan 26, 2021, 18:47 UTC
Message-ID: <xmqq8s8f3596.fsf@gitster.c.googlers.com>
In-Reply-To: <CAOLTT8T1N2FSK3GiLaQUZt-OO5qzjQz7iq2cuKxasmuwnEZoXw@mail.gmail.com>

胡哲宁 <adlternative@gmail.com> writes:

Show 18 quoted lines

> Junio C Hamano <gitster@pobox.com> 于2021年1月26日周二 下午2:17写道：
>>
>> "阿德烈 via GitGitGadget" <gitgitgadget@gmail.com> writes:
>>
>> > From: ZheNing Hu <adlternative@gmail.com>
>> >
>> > the usage in strbuf.h tell us"Alloc is somehow a
>> > "private" member that should not be messed with.
>> > use `strbuf_avail()`instead."
>>
>> When we use the word "private", it generally means it is private to
>> the implementation of the API.  IOW, it is usually fine for the
>> implementation of the API (i.e. for strbuf API, what you see in
>> strbuf.c) to use private members.
>>
> Well, I just think most other functions in strbuf.c follow the use
> of `strbuf_avail()` instead of "sb->alloc-sb->len-1", and the
> "sb->alloc-sb->len-1" that appears in `strbuf_read()` is not so uniform.

I actually wouldn't have minded if this were sold as "code clean-up to use _avail() when we open-code in the implementation of strbuf API in codepaths that are not performance critical."

I am not sure about the _setlen() side of the thing. It is quite obvious what is going on in the original, and it falls into "when it is written one way that is good enough, replacing it with another that is not significantly better often ends up being mere code churn.", I would think.

Thanks.