Re: [PATCH 2/9] add strip_suffix function
- From
Jeff King <peff@peff.net>
- Date
- Jul 2, 2014, 16:38 UTC
- Message-ID
- <20140702163832.GC14404@sigill.intra.peff.net>
- In-Reply-To
- <xmqqlhsbiwmz.fsf@gitster.dls.corp.google.com>
On Wed, Jul 02, 2014 at 08:54:44AM -0700, Junio C Hamano wrote:
Show 10 quoted lines
> Jeff King <peff@peff.net> writes: > > > For that reason, the "mem" form puts its length parameter > > next to the buffer (since they are a pair), and the string > > form puts it at the end (since it is an out-parameter). The > > compiler can notice when you get the order wrong, which > > should help prevent writing one when you meant the other. > > Very sensible consideration. I like commits that careful thinking > behind them shows through them.
I would like to take credit for advanced thinking, but I actually did what felt natural, and only noticed the "compiler will tell you when you are wrong" effect when I got it wrong while writing a later patch in the series. :)
Show 7 quoted lines
> If we want to avoid implying NUL-termination, the only way to do so
> would be to use wording that does not hint shortening. At least for
> the C-string variant, which is measuring the length of the basename
> part (i.e. `basename $str $suffix`) without touching anything else,
> e.g. basename_length("hello.c", ".c", &len), but at the same time
> you want to make it a boolean to signal if the string ends with the
> suffix, so perhaps has_suffix("hello.c", ".c", &len)?I think that invites some confusion with "ends_with", which is the same thing (but just does not take the "len" parameter). We could just add this feature to ends_with, and ask callers who do not care to pass NULL, but that makes those call sites uglier.
Having had a day to mull it over, and having read your email, I think I still prefer strip_suffix.
-Peff