From: Johannes Schindelin <Johannes.Schindelin@gmx.de>
To: Johannes Sixt <j6t@kdbg.org>
Cc: Junio C Hamano <gitster@pobox.com>,
Johannes Schindelin via GitGitGadget <gitgitgadget@gmail.com>,
git@vger.kernel.org
Subject: Re: [PATCH 1/1] Add a helper to reverse index_pos_to_insert_pos()
Date: Wed, 9 Oct 2019 10:17:58 +0200 (CEST) [thread overview]
Message-ID: <nycvar.QRO.7.76.6.1910091015090.46@tvgsbejvaqbjf.bet> (raw)
In-Reply-To: <623fcd51-5f0d-bc5b-f70d-0224a054ec5c@kdbg.org>
Hi Hannes,
On Wed, 9 Oct 2019, Johannes Sixt wrote:
> Am 09.10.19 um 03:19 schrieb Junio C Hamano:
> > Johannes Sixt <j6t@kdbg.org> writes:
>
> > After all, the primary purpose of
> > inventing the encoder was to catch the arith overflow, wasn't it?
>
> That was *your* motivation for the helper function. But IMO it is a
> wrong design decision.
I wish that comment, and the argument following it, would have come as
part of the review of the patch series that already made it to `next`.
FWIW I actually agree with Junio about the helper, but in hindsight I
could have used a better name (not one that is tied to the "index").
Something like `unsigned_one_complement()`. But of course, that would
say _what_ it does, not _why_.
And yes, I would wish we had C++ templates so that the helper could use
the exact type of the caller.
Ciao,
Dscho
> Whether or not the index calculation overflows is a matter of the type
> that is used for the index, and that in turn is dicated by the
> possible sizes of the collections that are indexed. IOW, the index
> overflow check is (*if* it is necessary) a policy decision that must
> be made at a higher level and must not be hidden away in a helper
> function whose purpose (as suggested by its name) is something
> entirely different.
>
> Unless, of course, we declare "all our indexes are of type int". But
> that ship has sailed long ago, because there are too many cases where we
> are forced to use size_t as index (strlen, sizeof...).
>
> Meta note: We know that we are painting a tiny shed here (Replacing a
> one-liner by a one-liner, huh?) If anyone of you has better things to
> do, please move on. My interest in this discussion are just the design
> decisions that are made, not the actual outcome of this particular case.
>
> -- Hannes
>
next prev parent reply other threads:[~2019-10-09 8:18 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-08 6:48 [PATCH 0/1] Fallout from azure-pipelines-msvc Johannes Schindelin via GitGitGadget
2019-10-08 6:48 ` [PATCH 1/1] Add a helper to reverse index_pos_to_insert_pos() Johannes Schindelin via GitGitGadget
2019-10-08 21:03 ` Johannes Sixt
2019-10-09 1:19 ` Junio C Hamano
2019-10-09 5:51 ` Johannes Sixt
2019-10-09 8:17 ` Johannes Schindelin [this message]
2019-10-09 11:44 ` Junio C Hamano
2019-10-09 11:59 ` Johannes Schindelin
2019-10-09 12:09 ` Junio C Hamano
2019-10-09 8:11 ` Johannes Schindelin
2019-10-09 8:15 ` Johannes Schindelin
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
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=nycvar.QRO.7.76.6.1910091015090.46@tvgsbejvaqbjf.bet \
--to=johannes.schindelin@gmx.de \
--cc=git@vger.kernel.org \
--cc=gitgitgadget@gmail.com \
--cc=gitster@pobox.com \
--cc=j6t@kdbg.org \
/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.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).