Interger over/under flow in C?

Is there a way to implement a portable way of detecting over and underflows in C?

Another thing, my asm code that handles this for now doesnt work either. I cant figure out why not.

asm ("overflow: "
     "xorl %eax, %eax \n"
     "jno O_Ret \n"
     "incl %eax \n"
     "O_Ret: ret\n");

nig_t fuck () {
  nig_t ass = tits + dick;
  if (overflow)
    return piss;
  if (underflow)
    return shit;
  return ass;
}
Now if i could figure out a way for this to work it would only work temporary, as i will need a portable way in the future anyway.

Any help would be appreciated.

>>39
That's also not guaranteed to be largest value.

>>41
Really? Because mathematically speaking it's logical NOT on all bits, for a specific type, with the starting point of all zeros. For all integer types that would be exactly the max value.

>>42
Think that over, read >>36 again. Can you see why this could fail?

>>43
"a result that cannot be represented by the resulting unsigned integer type is reduced modulo the number that is one greater than the largest value". Let's try reading that. For all bits, perform a logical not, and we can NEVER get a number larger than the largest representable value.

>>24
Yes.

There aren't many flaws in C. It's good at for what it's designed for.

>>43
If you're referring to how it won't work with signed types (not in the original problem), then just do ~(signed type)0 & ((type)1 << (sizeof(type)*CHAR_BIT-1))

Learn how to properly indent your code, please. Thanks.
http://en.wikipedia.org/wiki/Indent_style#Allman_style

>>47
Newb.
http://en.wikipedia.org/wiki/Indent_style#Variant:_1TBS

>>44
and we can NEVER get a number larger than the largest representable value.
This is false.

It's like I'm really in ##C!

C is shit. Use asm.

>>49
Then prove me wrong by counter example

>>52
What if one greater than UINT_MAX isn't a multiple of two?

>>53
It always is. Even IBM's BCD-capable processors are still just binary processors with glorified decimal accelerators. C defines bitwise operations for a reason.

It always is.
Please cite from the standard where you get this piece of information, it is new to me.

ITT: proof that being a C advocate and a C expert are mutually exclusive

>>55
Bitwise operations are well-defined on integer types within C and will break on any representation that isn't binary

>>57
Yeah they're well defined, independently of the value of UINT_MAX. But ~ (unsigned integer type) 0 isn't always UINT_MAX.

>>58
Maybe I wasn't clear enough: You can't compile C code for a non-binary processor because half the language becomes undefined.
Secondly, there are no processors in existence today that would even fall into that category. Hence, in C, for all integer types, ~(unsigned integer type)0 is the maximum value of that type.

What's an interger?

>>60
The interger titeracy friends.

>>59
You can't compile C code for a non-binary processor because half the language becomes undefined.
This is untrue, please cite from the standard where you found it or I will disregard it.

Secondly, there are no processors in existence today that would even fall into that category.
That is completely inconsequential, C is defined independently of what architectures currently exists.

Hence, in C, for all integer types, ~(unsigned integer type)0 is the maximum value of that type.
This still isn't true, please cite from the standard where you found this or I will disregard it.

>>62
Keep your eye on the ball, Paul.

>>63
Keep your eye on the mall, Hall.

>>63
Sorry. The Standard doesn't define eyes, balls, *or* Pauls.

>>62
What?

>>66
nice dubz

>>66
Keep your eye on the call, Saul.

gemini GET, sepplers

>>62
Bitwise operations are NOT defined for things that aren't represented by a binary vector. It's very simple, you can't define bitwise operations in ternary because it simply doesn't make sense to do so, and even more so for BCD. Every bitwise operation is undefined for non-binary processors. That accounts for your | & ^ and ~ operators. >> and << are bitshift operators that could be defined, but that would change their function to digit-shifting. In the exact same way that conventional programming languages don't execute on qubits, a large portion of C is undefined on anything not binary.

>>30
it's defined for unsigned types.
It really fucking isn't. Read the standard, dipshit.
6.5.3.3, paragraph 4:

The result of the ~ operator is the bitwise complement of its (promoted) operand (that is, each bit in the result is set if and only if the corresponding bit in the converted operand is not set). The integer promotions are performed on the operand, and the result has the promoted type. If the promoted type is an unsigned type, the expression ~E is equivalent to the maximum value representable in that type minus E.
I dislike morons like you, who have not read The Standard themselves, but kinda heard that it has a lot of undefined behaviour. Most of the things regarding unsigned types are actually well defined.

>>70
a large portion of C is undefined on anything not binary.
Shut the fuck up, moron, you don't understand the meaning of the word "defined".

The C standard defines how C works. When you want to make a C compiler for a ternary computer, you have to implement all arithmetic operations as described in the standard. If you use noncompliant native operations instead, then your compiler is not a C compiler, by definition. Things don't "become undefined" when your compiler sucks, your compiler sucks when your compiler sucks, that is all.

What you wanted to say was that it would be inefficient and kind of pointless to run C code on a ternary computer. If you are too dumb to form and express such a simple idea, and ramble about "things becoming undefined" and other bullshit instead, maybe you shouldn't try to contribute to discussions here.

>>71
>>30
You suck at referencing, quoting, and reading comprehension. We were talking about integer overflow, not bitwise complement.

>>72 oh, yes, I mostly wanted to tell off >>41, but the twisting idiocy of it all (including >>30) was hard to follow.

Point is, the C standard does almost completely[sup]*[/sub] define all operations on unsigned integer types, in a way that implies the usual binary representation. So overflows are defined, ~0 == (unsigned int)-1 == UINT_MAX, and so on, please stop this bullshit.

[*]: excepting things like division by zero, shifting by more than the width of the type, and so on.

>>73 I also seem suck at BBCode in general, today is not my day apparently :-(

>>73
So overflows are defined
Overflows are undefined, but can't happen with unsigned integer types.

C is shit.

Overflows are undefined.

>>71
arguing pointless semantics when you understand the meaning perfectly well
I'm leaving /prog/ and going to the far more pleasant ##C on FreeNode

>>78
Please, stay there too and (preferably) die in a fire along with your shitty undefined language.

Cast to long long before any calculations and then compare the result to MAX_INT. Certain compilers may have attributes or pragmas for detecting overflow, but those are non-standard. Also the xor in your x86 code wipes out the overflow flag and it wouldn't do what you want anyway even if labels worked that way and you're running it on 32-bit x86.