From: Jeff Hostetler <git@jeffhostetler.com>
Date: Mon, 26 Mar 2018 18:22:39 GMT
Subject: Re: [RFC PATCH v5 0/8] rebase-interactive
Message-ID: <d56a60a8-e735-b147-a2e6-4e48461ad701@jeffhostetler.com>
In-Reply-To: <xmqqh8p2d8jh.fsf@gitster-ct.c.googlers.com>



On 3/26/2018 1:57 PM, Junio C Hamano wrote:
> Jeff Hostetler <git@jeffhostetler.com> writes:
> 
>> I defined that routine to take a uint64_t because I wanted to
>> pass a nanosecond value received from getnanotime() and that's
>> what it returns.
> 
> Hmph, but the target format does not have different representation
> of inttypes in different sizes, no?
> 
> I personally doubt that we would benefit from having a group of
> functions (i.e. format_int{8,16,32,64}_to_json()) that callers have
> to choose from, depending on the exact size of the integer they want
> to serialize.  The de-serializing side would be the same story.
> 
> Even if the variable a potential caller of the formetter is a sized
> type that is different from uintmax_t, the caller shouldn't have to
> add an extra cast.
> 
> Am I missing some obvious merit for having these separate functions
> for explicit sizes?
> 

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.

Jeff