Re: lacking an unsigned MAX macro

[Francisco Olarte <folarte@...>]

Adam? ( due to sig vs source-email-address discrepancies I do not know
the proper way to start mails toyou )...

mmm..., reading this....
On Wed, May 15, 2019 at 8:31 PM Coda Highland <chighland@gmail.com> wrote:
> On Wed, May 15, 2019 at 12:56 PM Francisco Olarte <folarte@peoplecall.com> wrote:
....
>> (INTMAX - 0 + INTMIN)." it seemed ( and still seems to me ) he was
>> trying to redefine not arithmetically.

I should have quoted not, or used ~, but it seems I made myself understood.

> Ah, okay, that makes more sense. That's what I meant about the way it was phrased -- I thought he meant that's what the type coercion was doing (it's not).

He may have meant, I find is thought proccess puzzling at least.

> As a description of the arithmetic effect of the ~ operator... *crunches some numbers* It works for 1's complement and 2's complement for both signed and unsigned, but it only works for unsigned on a sign-magnitude system. (And INTMIN for an unsigned type is, obviously, 0.) This is fine according to the C spec because the spec only carries demands on the arithmetic behavior of bitwise operators for unsigned operations, but it does mean you can't quite say that expression is universally true across all conformant C implementations.

Yep. Thats why I normally try to find ways to leave this to compiler
implementers and avoid mixing logic and arithmetic behaviour, they
work hard at it and generally get things right. And I also act as if
"undefined behaviour" means "we will insert a chunk of code to brick
your hard disk" and not "we'll choose one of the two apparently normal
results" which some people use, saves a lot of trouble in the not so
long run, it doesn't usually bite, but when it does it does it hard.

Francisco Olarte.