views:

731

answers:

5

There are two unsigned ints (x and y) that need to be subtracted. x is always larger than y. However, both x and y can wrap around; for example, if they were both bytes, after 0xff comes 0x00. The problem case is if x wraps around, while y does not. Now x appears to be smaller than y. Luckily, x will not wrap around twice (only once is guaranteed). Assuming bytes, x has wrapped and is now 0x2, whereas y has not and is 0xFE. The right answer of x - y is supposed to be 0x4.

Maybe,

( x > y) ? (x-y) : (x+0xff-y);

But I think there is another way, something involving 2s compliment?, and in this embedded system, x and y are the largest unsigned int types, so adding 0xff... is not possible

What is the best way to write the statement (target language is C)?

+6  A: 

Maybe I don't understand, but what's wrong with:

unsigned r = x - y;

GMan
In case of bytes: `255 - ( - 10) = ?`
ThinkJet
He said both were unsigned.
GMan
+2  A: 

Assuming two unsigned integers (and a typical architecture where a subtraction of a-b, where a < b, doesn't do something strange):

  • If you know that one is supposed to be "larger" than the other, just subtract. It will work provided you haven't wrapped around more than once (obviously, if you have, you won't be able to tell).
  • If you don't know that one is larger than the other, subtract and cast the result to a signed int of the same width. It will work provided the difference between the two is in the range of the signed int (if not, you won't be able to tell).

To clarify: the scenario described by the original poster seems to be confusing people, but is typical of monotonically increasing fixed-width counters, such as hardware tick counters, or sequence numbers in protocols. The counter goes (e.g. for 8 bits) 0xfc, 0xfd, 0xfe, 0xff, 0x00, 0x01, 0x02, 0x03 etc., and you know that of the two values x and y that you have, x comes later. If x==0x02 and y==0xfe, the calculation x-y (as an 8-bit result) will give the correct answer of 4, asssuming a typical architecture.

Matthew Slattery
You describe exactly the situation I have. I was told I would have to account for the wrap and "use 2s compliment". I will have to try my system and see if it indeed gives the correct result.
mgag
@mgag: This only works for systems with two's complement. If you're on a sign-magnitude or ones' complement machine, the method "doesn't work". Once you overflow an `int`, it may or may not wrap around the same way everywhere.
Alok
If you're using an unsigned type in C, it is guaranteed to wrap around as described here, whether or not the system uses 2s complement (§6.2.5, paragraph 9: "A computation involving unsigned operands can never overflow, because 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 that can be represented by the resulting type.")
Stephen Canon
It bears repeating that Stephen is completely correct. unsigned arithmetic is completely defined in C, based on the width of the unsigned type.
caf
@Stephen: The OP changed the question, and initially his wording implied that he expected signed values to wrap around predictably. You are, of course, completely correct.
Alok
+2  A: 

The question, as stated, is confusing. You said that you are subtracting unsigned values. If x is always larger than y, as you said, then x - y cannot possibly wrap around or overflow. So you just do x - y (if that's what you need) and that's it.

AndreyT
`x - y` can wrap around if you're using signed ints.
jamesdlin
@jamesdlin: The subject of the question clearly and explicitly states that we are subtracting *unsigned* ints.
AndreyT
Oops, sorry. The content of the question itself said just "ints", but I forgot to pay attention to the title itself.
jamesdlin
A: 

To echo everyone else replying, if you just subtract the two and interpret the result as unsigned you'll be fine.

Unless you have an explicit counterexample.

Your example of x = 0x2, y= 0x14 would not result in 0x4, it would result in 0xEE, unless you have more constraints on the math that are unstated.

MSN
yeah that was a type - fixed now.
mgag
+1  A: 

Here's a little more detail of why it 'just works' when you subtract the 'smaller' from the 'larger'.

A couple of things going into this…
1. In hardware, subtraction uses addition: The appropriate operand is simply negated before being added.
2. In two’s complement (which pretty much everything uses), an integer is negated by inverting all the bits then adding 1.

Hardware does this more efficiently than it sounds from the above description, but that’s the basic algorithm for subtraction (even when values are unsigned).

So, lets figure 2 – 250 using 8bit unsigned integers. In binary we have

  0 0 0 0 0 0 1 0  
- 1 1 1 1 1 0 1 0

We negate the operand being subtracted and then add. Recall that to negate we invert all the bits then add 1. After inverting the bits of the second operand we have
0 0 0 0 0 1 0 1
Then after adding 1 we have
0 0 0 0 0 1 1 0

Now we perform addition...

  0 0 0 0 0 0 1 0   
+ 0 0 0 0 0 1 1 0

= 0 0 0 0 1 0 0 0 = 8, which is the result we wanted from 2 - 250
Purdude
interesting post
Atømix