qemu-ppc
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 02/19] host-utils: move abs64() to host-utils


From: Philippe Mathieu-Daudé
Subject: Re: [PATCH 02/19] host-utils: move abs64() to host-utils
Date: Wed, 25 Aug 2021 23:27:56 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0

On 8/25/21 11:18 PM, Eduardo Habkost wrote:
> On Wed, Aug 25, 2021 at 08:37:17PM +0000, Luis Fernando Fujita Pires wrote:
>> From: Eduardo Habkost <ehabkost@redhat.com>
>>
>>>> Right, that's true of any standard implementation of abs().
>>>> I thought about making it return uint64_t, but that could make it
>>>> weird for other uses of abs64(), where callers wouldn't expect a type
>>>> change from int64_t to uint64_t. Maybe create a separate uabs64() that
>>>> returns uint64_t? Or is that even weirder? :)
>>>
>>> Which users of abs64 would expect it to return int64_t?
>>> kvm_pit_update_clock_offset() doesn't seem to.
>>
>> Oh, I wasn't referring to any specific users. What I meant is
>> that, if we make abs64() generically available from host-utils,
>> callers could expect it to behave the same way as abs() in
>> stdlib, for example.
> 
> That would be surprising, but do you think there are cases where
> that would be a bad surprise?
> 
> I don't think anybody who is aware of the abs(INT_MIN),
> labs(LONG_MIN), and llabs(LLONG_MIN) edge cases actually _like_
> that behaviour.
> 
> If you really want to avoid surprises, providing a saner function
> with a different name seems better than trying to emulate the
> edge cases of abs()/labs()/llabs().

Agreed. See do_strtosz() for example.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]