Re: Computer architects leaving Intel...

David Brown wrote:

On 04/09/2024 22:31, Brett wrote:

David Brown <david.brown@hesbynett.no> wrote:

On 04/09/2024 14:53, jseigh wrote:

On 9/4/24 06:57, David Brown wrote:

On 04/09/2024 09:15, Terje Mathisen wrote:

David Brown wrote:

>

Maybe?
>
Rust will _always_ check for such overflow in debug builds, then when
you've determined that they don't occur, the release build falls back
standard CPU behavior, i.e. wrapping around with no panics.

>
But if you've determined that they do not occur (during debugging),
then your code never makes use of the results of an overflow - thus
why is it defined behaviour?  It makes no sense.  The only time when
you would actually see wrapping in final code is if you hadn't tested
it properly, and then you can be pretty confident that the whole thing
will end in tears when signs change unexpectedly.  It would be much
more sensible to leave signed overflow undefined, and let the compiler
optimise on that basis.
>

>
You absolutely do want defined behavior on overflow.

>
No, you absolutely do /not/ want that - for the vast majority of use-cases.
>
There are times when you want wrapping behaviour, yes.  More generally,
you want modulo arithmetic rather than a model of mathematical integer
arithmetic.  But those cases are rare, and in C they are easily handled
using unsigned integers.

>
I tried using unsigned for a bunch of my data types that should never go
negative, but every time I would have to compare them with an int somewhere
and that would cause a compiler warning, because the goal was to also
remove unsafe code.
>
Complete and udder disaster, went back to plain sized ints.
>

>
That's a matter of choice in the warnings you pick and the style you use - these should match.
>
However, I don't think C's integer promotion rules are ideal in regard to mixing signed and unsigned arithmetic - converting both to "unsigned" can easily lead to trouble.
>
Some people recommend using unsigned int everywhere you can, because the overflow behaviour is defined - I think that is simply wrong.  Use unsigned int where it is appropriate, but it is very rare (though it happens sometimes) that you want any arithmetic to overflow in any way. So the justification is wrong.
>
Some people like to use unsigned int when the values will not be negative.  I don't think that is a good idea either.  In general, for any given use you only need a limited range of values.  0 to 10000 is just as much a subset of "int" as "unsigned int", and using "unsigned int" does not give any advantages.  On the contrary, using "int" can give more efficient code in many places, and lets you enable warnings about mixed unsigned / signed operations for when you actually want them.
>
Unsigned types are ideal for "raw" memory access or external data, for anything involving bit manipulation (use of &, |, ^, << and >> on signed types is usually wrong, IMHO), as building blocks in extended arithmetic types, for the few occasions when you want two's complement wrapping, and for the even fewer occasions when you actually need that last bit of range.

 That last paragraph enumerates pretty much all the uses I have for integer-type variables, with (like Mitch) a few apis that use (-1) as an error signal that has to be handled with special code.
 

>
It would be nice if C had subrange types like Pascal or Ada, but it does not.  Usually int - or sizeed ints - are the practical choice.

  Agreed 100%
 I wrote enough Pascal with ranged types that I got used to it, and found that I was missing the feature when I used C.
 Terje