unsigned short promotes to SIGNED int?! why... why did you do this to us C ?!
want!
🇳🇱
depending on your system a short may always be backed by an int simply due to hardware constraints. In fact that is rather common.
@freemo why unsigned to signed though? Usual justification for promotion is that it costs nothing and helps avoid overflow, but in case of unsigned short to signed int, multiplication is still likely to overflow. To make matters worse singed overflow is undefined behavior -_-
@namark Only time signed promotion should occur is when one type is signed and the other unsigned, therefore the result promotes to signed to encapsulate the signed result. Its the same reason to avoid overflow.
Do you hsome other example in mind that is different than this?
@freemo are you referring to the rule set in the link I provided? Should have been more clear that that's a c++ library that fixes the problem (that I "want!"). The language standard is that even two unsigned shorts will be promoted to signed int. The logic is as long as it fits in singed int it will be promoted to singed, and only if it doesn't would it be unsigned. Any unsigned short would fit in singed int, but their multiplication might not (at least in common architectures).
@namark I was refering to the promotion that occurs in the C language, the very thing the link you are providing is trying to correct by imposing its own rules that they feel is more sane.
I thought you were complaining about C's natural rules (people often say they are broken), not complaining about the libraries proposed fix to them. My fault.
@namark no in c two unsigned shorts would promote to an unsigned in not signed, usually... you get the followng:
unsigned short = 0
unsigned short = 1
printf("%u\n", x - y);
//prints an unsigned int: 4294967295
There are cases where unsigned will be promoted to signed but that would need a mixed case with atleast on signed in it like this:
unsigned short = 1
signed short = -2
printf("%u\n", x - y);
//prints a signed int: -1
@freemo nope, your second example doesn't print what you say it does, and it couldn't ever print anything negative, cause you are casting the result to unsigned with printf %u. Replace it with %i and woah you proved the opposite.
Look up the rules, anything that can fit into signed int is promoted to singed int regardless of signedness, and regardless if the result of operation can fit. I cant be bothered to device an example in C where you can in some weird indirect way notice this due to sign extension, so here is a c++ example that demonstrates it directly:
template <typename> class show_type;
void f()
{
unsigned short a, b;
show_type<decltype(a*b)> x;
}
It should give you an error about incomplete type show_type<int>, the template parameter indicating the type of the result of the multiplication.
@namark sorry the %u was a typo, I was copying from an example and copied the wrong line.. here is a clearer version of what I mean, showing the type conversion I stated is the case (it is only my print function that masked that):
unsigned int a = 1;
signed int b = -2;
if(a + b > 0)
puts("-1 is larger than 0");
^^ That will print
@freemo Right, comparison could be a good way to show it in C. Applied to your first example you can see the result will be less < 0, however that is a good case, no threat of overflow there and the safe numerics wrapper will do the same. Multiplication is the problem:
unsigned short a = 0xFFFF;
unsigned short b = 0xFFFF;
if(a * b < 0)
puts("oh no!");
Though since it's undefined behaviour you can't be sure in anything! Here is a more complete example to demonstrate that:
https://coliru.stacked-crooked.com/a/d91be42d25ddf8ff
The safe numeric wrapper will do the right thing here and promote to unsigned int, that can hold the result without overflow.
@namark yea well "undefined behavior" is kinda most of the issue with a lot of C, and it is more by design. Not saying that excuses it mind you, I understand your frustration. There is a reason most people feel it is the most broken aspect of C.
Me I learned to live with it try to be aware of it and thats it.. probably because i deal with so many languages if i was critical of their failings I'd be constantly complaining. I have yet to find the perfect language to my personal ideology.
@freemo undefined behavior is wonderful, beautiful and necessary and I love it, the promotion rules are broken, and the result happens to be devastating. If signed overflow was totally defined behavior, it would still be bad, even if not as devastating.
@namark Fair, personally if it were up to me in C I'd rather see no type promotion of any kind and I'd leave it up to the programmer to worry about overflow. While I would be ok with type promotion (when sane) in an interpreted language I feel in a language like C/C++ that intends to live close to the hardware it does more harm than good.
@freemo I want all the variants, promotion, no promotion, customized promotion, demotion(?), lateral motion(??). That's what c++ is usually about, every use case is respected and everything is optional on top of c.
@namark fair. I find if im doing C or C++ type promotion gets in the way and has never been a benefit for me, but to each their own. Its something i dont mind too much though and can code for it all the same.
@freemo Oh no I made the confusion worse. I was indeed complaining about C. It's C's rule that two unsigned shorts promote to signed int. I agree with the library I linked, though would have been even better if it allowed more customization.