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

On Tue, Sep 21 2021, Jeff King wrote:

On Tue, Sep 21, 2021 at 05:17:57PM +0200, Ævar Arnfjörð Bjarmason wrote:

quoted

On Tue, Sep 21 2021, Jeff King wrote:

quoted

On Tue, Sep 21, 2021 at 02:45:16PM +0200, Ævar Arnfjörð Bjarmason wrote:

quoted

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...