Re: [PATCH 6/5] grep.c: mark eol/bol and derived as "const char * const"

From: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Date: Sep 23, 2021, 13:56 UTC
Message-ID: <874kab5r63.fsf@evledraar.gmail.com>
In-Reply-To: <YUowCkmWqKgIldNz@coredump.intra.peff.net>

On Tue, Sep 21 2021, Jeff King wrote:

Show 21 quoted lines

> On Tue, Sep 21, 2021 at 05:17:57PM +0200, Ævar Arnfjörð Bjarmason wrote:
>
>> 
>> On Tue, Sep 21 2021, Jeff King wrote:
>> 
>> > On Tue, Sep 21, 2021 at 02:45:16PM +0200, Ævar Arnfjörð Bjarmason wrote:
>> >
>> >> I think that generally git's codebase could use going beyond just
>> >> "const char *" when a "const char * const" would suffice, for some
>> >> reason we seem to mostly use it for the static usage variables.
>> >
>> > I didn't dig up the references in the list archive, but I feel like
>> > we've had this discussion long ago. One of the reasons not to do so is
>> > that it pollutes the function's interface with internal details.[...]
>> 
>> Are there cases in my conversion where the caller has to do anything
>> special that they didn't before? These are also all static functions, so
>> it's all internal details exported to nobody.
>
> No, they don't have to do anything differently. I just meant that it
> clutters the interface when a human is reading it.

Fair enough, to this human reading it (and I'm not new to the grep.c code) I find myself trying and failing to mentally track what gets modified where, but anyway, I think that point is understood and I won't argue for it ad nauseum.

Just replied to say to Junio's <xmqqh7ec77s3.fsf@gitster.g> in the side-thread:

> Yes.  "This pointer is not modified" is a good thing to have inside
> an implementation, but the callers should not have to care.

That I just don't understand, i.e. how the variable is defined in this 6/5 pertains to how it gets used /inside/ the function in this case, the caller code doesn't have to care, but perhaps I'm missing something...