In article <tu4pi3$nhe$1@news.misty.com>,
Johnny Billquist <bqt@softjar.se> wrote:
>On 2023-03-03 13:42, bill wrote:
>> On 3/3/2023 6:59 AM, Johnny Billquist wrote:
>>> Damn! I learned something new today...
>>>
>>> On 2023-03-01 15:54, Dan Cross wrote:
>>>> In article <ttnk0m$lg5$2@news.misty.com>,
>>>> Johnny Billquist  <bqt@softjar.se> wrote:
>>>>> On 2023-02-28 20:11, Dan Cross wrote:
>>>
>>> [...]
>>>
>>>>> You overcomplicated the whole explanation.
>>>>
>>>> Hmm.
>>>
>>> I was wrong. :-)
>>>
>>>>> Basically, if you multiply two numbers, and the result would be bigger
>>>>> than the types involved, the result is undefined.
>>>>
>>>> Well...no.  _unsigned_ integer overflow in C is well-defined (it
>>>> has modular wrapping semantics; C11 sec 6.2.5 para 9).
>>>> Similarly, overflow of signed atomics is well-defined (C11 sec
>>>> 7.17.7.5 para 3), so this is not always true.
>>>
>>> I had actually missed that unsigned integers do have a defined
>>> overflow behavior. Thanks.
>>>
>>>>> In this case, the type
>>>>> is unsigned short. If the multiplication cause anything that don't fit
>>>>> into an unsigned short, then the result is undefined.
>>>>>
>>>>> And it's fairly easy to find two unsigned short numbers that when
>>>>> multiplied will give a result that don't fit into an unsigned short.
>>>>
>>>> The range of unsigned short has little to do with it, and
>>>> truncation of the result is fine too (again, defined to use
>>>> modular wrapping for unsigned types; C11 sec 6.3.1.3).  The
>>>> problem is entirely due to the promotion to _signed_ int prior
>>>> to the multiplication.  The fix, incidentally, is easy:
>>>>
>>>> unsigned short
>>>> mul(unsigned short a, unsigned short b)
>>>> {
>>>>     unsigned int aa = a, bb = b;
>>>>     return aa * bb;
>>>> }
>>>>
>>>> This is well-defined, even if the range of `unsigned short` is
>>>> the same as `unsigned int`, which is permitted by the standard.
>>>
>>> Right. My second error. It is allowed to promote a unsigned short to a
>>> signed int.
>>> I do feel that I don't entirely agree with that rule, but it's
>>> definitely written as such.
>>>
>>> Changing from unsigned to signed feels just as a freedom too much.
>>>
>>>>> It's really not that different from any other language. Some languages
>>>>> will throw an exception, others will just give some result that
>>>>> might or
>>>>> might not be meaningful. But there is no guarantee in almost any
>>>>> language of some kind of specific meaningful result. Try it in FORTRAN
>>>>> and see what you get there, or Cobol (or BASIC). :-)
>>>>
>>>> The issue, and the reason for the complex initial explanation,
>>>> is the subtle interaction between the implicit type promotion
>>>> rules, arithmetic, undefined behavior, and the freedom that UB
>>>> gives to compiler writers, which is pretty unique to C.  Hence
>>>> why optimizing compilers often _appear_ to introduce bugs when
>>>> in fact they're performing perfectly legal transformations, and
>>>> turning off the optimizer can appear to "fix" the problem.
>>>
>>> Yup. You were right. Sorry that I had to go and read the spec again.
>>> Trusting my brain was obviously the wrong thing to do.
>>>
>>
>> And it really doesn't matter whether the result is truncation,
>> conversion to signed int, wrap around, throwing an exception or
>> undefined.  The answer is still going to be wrong and the calculation
>> worthless.  So, what's the point?  Fix the damn code.
>>
>> Go ahead, blame the language again.
>
>No. I don't fully agree. The fact that unsigned types are defined to
>have the wrapping behavior means that you could definitely do this
>intentionally and for rather good reasons.
>
>But the type propagation rule here breaks that promise, which is what I
>find *very* broken. I do consider it a error in the language
>specification when this can happen.

In fairness to C (!!), this only happens for types that are
lower "rank" than `int`, where "rank" is defined in C11 sec
6.3.1.1. So if I start with an `unsigned int` and do my
arithmetic, the implicit conversion to a larger signed type
won't happen; the issue is when one starts with smaller types.

Hence why the `mul` example is fixed by assignment to
intermediate `unsigned int`s:

unsigned short
mul(unsigned short a, unsigned short b)
{ unsigned int aa = a;
unsigned int bb = b;
return aa * bb;
}

Of course, these rules are sufficiently obtuse, and so easy to
accidentally misuse, that I have to agree with your assessment
that this feels like a bug in the language.

- Dan C.

On 2023-03-06 23:07, Dan Cross wrote:
> In article <tu4pi3$nhe$1@news.misty.com>,
> Johnny Billquist <bqt@softjar.se> wrote:
>> On 2023-03-03 13:42, bill wrote:
>>> Go ahead, blame the language again.
>>
>> No. I don't fully agree. The fact that unsigned types are defined to
>> have the wrapping behavior means that you could definitely do this
>> intentionally and for rather good reasons.
>>
>> But the type propagation rule here breaks that promise, which is what I
>> find *very* broken. I do consider it a error in the language
>> specification when this can happen.
>
> In fairness to C (!!), this only happens for types that are
> lower "rank" than `int`, where "rank" is defined in C11 sec
> 6.3.1.1. So if I start with an `unsigned int` and do my
> arithmetic, the implicit conversion to a larger signed type
> won't happen; the issue is when one starts with smaller types.
>
> Hence why the `mul` example is fixed by assignment to
> intermediate `unsigned int`s:
>
> unsigned short
> mul(unsigned short a, unsigned short b)
> {
> unsigned int aa = a;
> unsigned int bb = b;
> return aa * bb;
> }
>
> Of course, these rules are sufficiently obtuse, and so easy to
> accidentally misuse, that I have to agree with your assessment
> that this feels like a bug in the language.

Since unsigned and signed have more implications than just the ability
to contain negative numbers (in this case, the explicit definition that
arithmetic are done modulo the size of the storage for unsigned), I
believe it is inherently wrong to allow an unsigned integer to be
silently promoted to a larger signed integer.

Basically, since unsignedness implies more than just the range of
values, it can never be right to promote to a type with other
implications (signed in this case). Signed values inherently have other
properties, so they are not equal enough to be allowed to be moved
silently between.

I had totally missed that unsigned values are guaranteed to do modulo
arithmetic before. Although I've used it plenty, and find it extremely
useful, I always assumed it wasn't guaranteed by the language (and I was
just lucky), and I might even have seen examples where it broke for
optimized code. But I now suspect that was really when dealing with
signed values.
(I did at least once hit upon a compiler optimization which removed a
whole chunk of code because the compiler was moving between unsigned and
signed, and basically figured out the value could never be negative,
even though in reality it was. But it was all because of undefined
behavior, or implementation specific. So I've had to deal with these
wonders a few times already, and have become wary of assuming almost
anything...)

Johnny