Re: o3tl::make_unsigned

[Kaganski Mike <mikekaganski@xxxxxxxxxxx>]

On 2020-01-30 15:30, Stephan Bergmann wrote:
> On 30/01/2020 12:56, Luboš Luňák wrote:
>> On Thursday 30 of January 2020, Stephan Bergmann wrote:
>>> On 29/01/2020 17:14, Luboš Luňák wrote:
>>>>    Exactly my point. It's just that you seem to find it guaranteed that
>>>> people won't mess up range checks and only likely there won't be
>>>> titanically huge files/allocations/containers, and I see it the 
>>>> other way
>>>> around. So far I've definitely seen more often somebody get >=0 wrong
>>>> than I've seen 8 exabytes of anything.
>>>
>>> My point is that, for e1 of signed type S1 (where U1 is the unsigned
>>> counterpart) and e2 of unsigned type U2 (where S2 is the signed
>>> counterpart),
>>>
>>>     e1 < 0 || U1(e1) < e2  // (*)
>>>
>>> is guaranteed to work for all types S1 and U2 and all values of e1 and
>>> e2, while
>>>
>>>     e1 < S2(e2)
>>>
>>> is not.  My point has nothing to do with people writing broken code, or
>>> how to prevent them from doing so.
>>>
>>> It is just that for the task "compare a signed e1 against an unsigned
>>> e2", (*) is the tool I at least reach for (naturally; without much of a
>>> second thought, actually).  And it has in fact been used all over the LO
>>> code base,
>>
>>   This contradicts your original mail, where you stated that what is used
>> is "if (sal_uInt32(e1) < e2) ...    // (B)" (i.e. without the <0 
>> check). And
> 
> Maybe it is unclear, but my original mail was talking about a "correct" 
> comparison
> 
>    e1 < e2
> 
> (i.e., where it is known that e1 >= 0, but where compilers might 
> nevertheless emit a signed-vs.-unsigned warning).

Can the hypothetical make_signed function return a signed integer when 
there's a bigger integer type exist, and a struct with overloaded 
operator<=> when there's not, and that overloaded operator<=> would 
check if contained unsigned value is greater than max value of its 
signed argument, and return "contained unsigned is greater than passed 
signed" in that case, otherwise fallback to "convert unsigned to signed 
and compare normally" strategy? This would comply with the scope of the 
function (which, as I understand it, to only be used in preparation to 
comparison), always return mathematically correct result of comparison, 
and allow all smaller types comparison to still be without overhead? 
(But for 64-bit unsigned types, of course, it will introduce the 
overhead. Will it be significant, though?)

-- 
Best regards,
Mike Kaganski
_______________________________________________
LibreOffice mailing list
LibreOffice@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/libreoffice