Re: [RFC PATCH v5 0/8] rebase-interactive

From: Junio C Hamano <gitster@pobox.com>
Date: Mar 27, 2018, 05:07 UTC
Message-ID: <xmqqy3ie9kdv.fsf@gitster-ct.c.googlers.com>
In-Reply-To: <d56a60a8-e735-b147-a2e6-4e48461ad701@jeffhostetler.com>

Jeff Hostetler <git@jeffhostetler.com> writes:

Show 6 quoted lines

> I did the uint64_t for the unsigned ns times.
>
> I did the other one for the usual signed ints.
>
> I could convert them both to a single signed 64 bit typed function
> if we only want to have one function.

I still think having sized version is a horrible idea, and recommend instrad to use "the widest possible on the platform" type, for the same reason why you would only have variant for double but not for float.

intmax and uintmax are by definition wide enough to hold any value that would fit in any integral type the platform supports, so if a caller that wants to handle 64-bit unsigned timestamp for example uses uint64_t variable to pass such a timestamp around, and the platform is capable of groking that code, you should be able to safely pass that to json serializer you are writing that takes uintmax_t just fine, and (1) your caller that passes around uint64_t timestamps won't compile on a platform that is incapable of doing 64-bit and you have bigger problem than uintmax_t being narrower than 64-bit on such a platform, and (2) your caller can just pass uint64_t value to your JSON formatter that expects uintmax_t without explicit casting, as normal integral type promotion rule would apply.

So I would think it is most sensible to have double, uintmax_t and intmax_t variants. If you do not care about the extra value range that unsigned integral types afford, a single intmax_t variant would also be fine.