From: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
To: Jeff King <peff@peff.net>
Cc: git@vger.kernel.org, Junio C Hamano <gitster@pobox.com>,
Hamza Mahfooz <someguy@effective-light.com>,
Taylor Blau <me@ttaylorr.com>
Subject: Re: [PATCH 6/5] grep.c: mark eol/bol and derived as "const char * const"
Date: Thu, 23 Sep 2021 15:56:21 +0200 [thread overview]
Message-ID: <874kab5r63.fsf@evledraar.gmail.com> (raw)
In-Reply-To: <YUowCkmWqKgIldNz@coredump.intra.peff.net>
On Tue, Sep 21 2021, Jeff King wrote:
> 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...
next prev parent reply other threads:[~2021-09-23 13:59 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-09-21 3:45 [PATCH 0/5] const-correctness in grep.c Jeff King
2021-09-21 3:46 ` [PATCH 1/5] grep: stop modifying buffer in strip_timestamp Jeff King
2021-09-21 5:18 ` Carlo Arenas
2021-09-21 5:24 ` Eric Sunshine
2021-09-21 5:40 ` Carlo Arenas
2021-09-21 5:43 ` Jeff King
2021-09-21 6:42 ` Carlo Marcelo Arenas Belón
2021-09-21 7:37 ` René Scharfe
2021-09-21 14:24 ` Jeff King
2021-09-21 21:02 ` Ævar Arnfjörð Bjarmason
2021-09-22 20:20 ` Jeff King
2021-09-23 0:53 ` Ævar Arnfjörð Bjarmason
2021-09-21 3:48 ` [PATCH 2/5] grep: stop modifying buffer in show_line() Jeff King
2021-09-21 4:22 ` Taylor Blau
2021-09-21 4:42 ` Jeff King
2021-09-21 4:45 ` Taylor Blau
2021-09-21 3:48 ` [PATCH 3/5] grep: stop modifying buffer in grep_source_1() Jeff King
2021-09-21 3:49 ` [PATCH 4/5] grep: mark "haystack" buffers as const Jeff King
2021-09-21 12:04 ` Ævar Arnfjörð Bjarmason
2021-09-21 14:27 ` Jeff King
2021-09-21 3:51 ` [PATCH 5/5] grep: store grep_source buffer " Jeff King
2021-09-21 4:30 ` [PATCH 0/5] const-correctness in grep.c Taylor Blau
2021-09-21 12:07 ` Ævar Arnfjörð Bjarmason
2021-09-21 14:49 ` Jeff King
2021-09-21 12:45 ` [PATCH 6/5] grep.c: mark eol/bol and derived as "const char * const" Ævar Arnfjörð Bjarmason
2021-09-21 14:53 ` Jeff King
2021-09-21 15:17 ` Ævar Arnfjörð Bjarmason
2021-09-21 19:18 ` Jeff King
2021-09-23 13:56 ` Ævar Arnfjörð Bjarmason [this message]
2021-09-24 4:22 ` Junio C Hamano
2021-09-22 19:02 ` Junio C Hamano
2021-09-22 18:57 ` [PATCH 0/5] const-correctness in grep.c Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=874kab5r63.fsf@evledraar.gmail.com \
--to=avarab@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=me@ttaylorr.com \
--cc=peff@peff.net \
--cc=someguy@effective-light.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.