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 <ehabk...@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.
