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(). -- Eduardo