Re: [PATCH 3/3] reftable tests: avoid "int" overflow, use "uint64_t"

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Jan 12, 2022, 14:18 UTC
Message-ID: <nycvar.QRO.7.76.6.2201121515490.2121@tvgsbejvaqbjf.bet>
In-Reply-To: <Yd3njKcopXVZ+69C@nand.local>

Hi Taylor,

On Tue, 11 Jan 2022, Taylor Blau wrote:

Show 26 quoted lines

> On Tue, Jan 11, 2022 at 09:21:11PM +0100, Johannes Sixt wrote:
> > Am 11.01.22 um 21:18 schrieb Taylor Blau:
> > > On Tue, Jan 11, 2022 at 09:08:46PM +0100, Johannes Sixt wrote:
> > >> Am 11.01.22 um 20:41 schrieb Taylor Blau:
> > >>> On Tue, Jan 11, 2022 at 08:31:47PM +0100, Han-Wen Nienhuys wrote:
> > >>>> On Tue, Jan 11, 2022 at 8:28 PM Taylor Blau <me@ttaylorr.com> wrote:
> > >>>>> In any case, you're only setting the lower half of `min` high. Maybe:
> > >>>>>
> > >>>>>     uint64_t min = ~0ul;
> > >>>>
> > >>>> yeah, that works.
> > >>>
> > >>> I'm pretty sure this is OK on 32-bit systems, too, but confirmation from
> > >>> somebody more confident than I in this area would be welcome :).
> > >>
> > >> It does not work on Windows: unsigned long is 32 bits wide. You have to
> > >> make it
> > >>
> > >>    uint64_t min = ~(uint64_t)0;
> > >
> > > Perfect; this is exactly what I was looking for. Thanks!
> >
> > Actually, on second thought, UINT64_MAX would be even better.
>
> :-). I think that either is probably fine; I couldn't remember if
> UINT64_MAX was part of POSIX or not (and clearly didn't bother to check!)

The best solution, of course, would be to `git grep` through the code and see that UINT64_MAX is not used at all.

And that brings us to the question whether we really need to ensure that exactly, precisely 64 bit are used for this variable? The answer is: no. We may need it to be larger than 32-bit, so why not go for `uintmax_t` and `UINTMAX_MAX`, both of which _are_ already used in Git's source code?

Ciao, Dscho