From: david.brown@hesbynett.no   
      
   On 21/10/2025 20:44, James Kuyper wrote:   
   > On 2025-10-21 06:42, David Brown wrote:   
   >> On 20/10/2025 22:09, Kaz Kylheku wrote:   
   >>> On 2025-10-20, David Brown  wrote:   
   >>>> On 20/10/2025 17:03, pozz wrote:   
   > ...>> However using unsigned types due to them being safe is often poorly   
   >>> considered because if something goes wrong contrary to the programmer's   
   >>> intent, there likely will be undefined behavior somewhere.   
   >>   
   >> Exactly.  Unsigned types are not somehow "safer" than signed types, just   
   >> because signed types have UB on overflow.  Don't overflow your signed   
   >> types, then you have no UB.  And if you overflow your unsigned types   
   >> without that being an intentional and understood part of your code, you   
   >> will at the very least get unexpected behaviour - a bug - and just like   
   >> UB, there are no limits to how bad that can get.   
   >   
   > No, there are limits on unexpected behavior: being unexpected, you might   
   > not know what they are, but it is still the case that the behavior   
   > starts out with having nothing more than an expression with an   
   > unexpected but valid value. That's pretty bad, and your code might make   
   > it worse, for example by promoting the unexpected value into undefined   
   > behavior. However, unless and until it actually does so, the behavior is   
   > somewhat more restricted than UB.   
      
   The effect of "unexpected behaviour" - something that has well-defined   
   behaviour according to the C standard or the implementation, but was not   
   what the programmer had intended or expected - is clear at the point it   
   happens.  Your unsigned arithmetic overflows in a defined and specified   
   manner.  But the knock-on effects are, in general, unpredictable - there   
   are no specific limits for how bad things can get.  It is not unlikely   
   that you'll end up with "real" UB.  In theory, real UB can lead to   
   launching of nasal daemons, while unexpected behaviour, if it does not   
   lead to real UB, cannot launch nasal daemons unless you have nasal   
   daemon launch procedures in your program.  In practice, real UB can more   
   often lead to a quick crash and perhaps "nicer" bad behaviour (via OS   
   memory protections and the like), while the unexpected behaviour can   
   continue on, quietly causing future havoc and problems that are harder   
   to find and debug.  Either way, I think we can agree that bad things can   
   happen!   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)