"(INTMAX - 0 + INTMIN)" was incorrect yes, I should have reread it because there were sign errors.
Coda:
On Wed, May 15, 2019 at 3:41 PM Coda Highland <chighland@gmail.com> wrote:
> On Wed, May 15, 2019 at 4:40 AM Francisco Olarte <folarte@peoplecall.com> wrote:
...
>> You've got a weird concept of simple. Why go through this arithmetic
...
> This is talking about the standard behavior, not about the implementation details. He's got things a little bit mixed up, which ended up making him wrong, and that's making the communication noisy, but I went and looked up the C language specification to be sure.
Oh, I inferred what he was trying to point ( although I think he did
it the other way round, I do not read Philippe's post in detail, I
think he has got all the programming languages concepts mixed from his
personal world view, I just like to yank his chain a bit ocasionally
).
> It's not the ~ operator that has that behavior. The ~ operator is always bitwise negation. ~0 on a 1's complement machine would be a negative zero. ~0 on a sign-magnitude machine would be INT_MIN (which is equal to -INT_MAX on those platforms instead of -INT_MAX - 1).
Yeah, that is what I was pointint. I'm nearlly sure C has the not
operator because the pdp-7/11 had(s) NOT or XOR R,imm in the
instruction set.
> However, the way the spec is written,
...
I've read the spec, but, when he said " then it computes the
bit-inversion (i.e. its a simple arithmetic addition: substract the
value from the maximum of its input type and adds the minimum of that
type); as this input type is an int, , it returns an int equal to
(INTMAX - 0 + INTMIN)." it seemed ( and still seems to me ) he was
trying to redefine not arithmetically.
FOS.
