Negative Integer Comparisons

Question

I am trying to compare two integers. One is the row of an NSIndexPath, the other is the count of an NSArray. The row is equal to 0 and the count is equal to 2. I have them in an if statement as follows:

if([self.selectedSetpoint row] < ([self.theCategories count]-3))
{
    //Do true stuff
}

So by my math, the if statement should be false as I am comparing 0 < -1. However, I keep getting this statement coming through as true, and the block inside the if is being run. I have tried to NSLog the values to make sure that I am not just getting the wrong value. I placed this right BEFORE the if statement:

NSLog(@"%d",[self.selectedSetpoint row]);
NSLog(@"%d",[self.theCategories count]-3);
NSLog(@"%@",[self.selectedSetpoint row] < ([self.theCategories count]-3)?@"Yes":@"No");

and got this on the console:

2012-07-17 08:58:46.061 App[61345:11603] 0
2012-07-17 08:58:46.061 App[61345:11603] -1
2012-07-17 08:58:46.062 App[61345:11603] Yes

Any ideas why this comparison is coming up as true? Am I misunderstanding something about comparing integers?

I have another if statement just above this one that compares

[self.selectedSetpoint row]<([self.theCategories count]-2)

Which is 0 < 0, and it works fine (returns NO). So I feel like there is some issue with the use of negative integers that I am not getting.

Thank you in advance.

If you meant -1 should be +1, you can use ABS(theCategories.count) so it returns absolute value of integer. — Samet DEDE, Jul 17 '12 at 14:21
Is it not because you are comparing an NSUInteger with an NSInteger? — Luke, Jul 17 '12 at 14:22
@EPyLEpSY no, I'm not trying to get the absolute value, I want it to compare 0 and -1. — Justin Paulson, Jul 17 '12 at 14:24
@Luke I don't know, is count unsigned? I figured if I got -1 in the log that I was going to get -1 in the comparison. — Justin Paulson, Jul 17 '12 at 14:24
The index path's row is an int whereas the array's count is unsigned. — Luke, Jul 17 '12 at 14:24
Hey @Luke, I didn't see your comment here until after I posted my answer. I'm pretty sure that's exactly the issue (I tested and reproduced his results with a fix being to cast as int). Perhaps you should post an answer too and get some rep out of it! — Chris Trahey, Jul 17 '12 at 14:29
I don't usually have faith in my comments.... guess it's a bit late now with all the answers posted :) — Luke, Jul 17 '12 at 14:34
@Luke, you are correct, had it been an answer I would have taken it :) — Justin Paulson, Jul 17 '12 at 14:34

score 7 · Accepted Answer · answered Jul 17 '12 at 14:27

I suspect the issue is that the return of count is an unsigned integer, and subtracting more than it's magnitude, it underflows and becomes quite large. I have run some tests, and I get the same basic behavior as you (it looks like it's -1, and in certain contexts it appears to be working as expected... however it is clearly being underflowed in the context of the if() block.

Silly problem, but luckily there is a simple solution: Cast it in place in the if statement:

if([self.selectedSetpoint row] < ( (int)[self.theCategories count] -3 ))
{
    //Do true stuff
}

What a rookie mistake! Thanks! – Justin Paulson Jul 17 '12 at 14:33 — Justin Paulson, Jul 17 '12 at 14:33

score 2 · Answer 2 · edited May 23 '17 at 11:51

I was going to propose an alternative solution - namely to avoid using subtraction and instead use addition on the other side of the equation:

if ([self.selectedSetpoint row] + 3 < [self.theCategories count])
{
    //Do true stuff
}

This sidesteps getting caught by these kind of underflow bugs, however it leaves another gotcha untouched... Namely the conversion rules referred to in the answer to this question: What are the general rules for comparing different data types in C?

Quoting from an answer to that question, you see the C99 spec states:

(when one operand is signed and the other unsigned) Otherwise, if the operand that has unsigned integer type has rank greater or equal to the rank of the type of the other operand, then the operand with signed integer type is converted to the type of the operand with unsigned integer type.

So if you have a negative value for [self.selectedSetpoint row] + 3 then the comparison will fail...

The other answers here have advocated casting (NSUInteger) to (NSInteger) - but note that this may cause overflow problems if your unsigned values are significantly massive. For e.g:

(NSInteger) -3 < (NSInteger) 4294967289 == false...

Figuring there must be an easy way to solve this, I first came up with a hard way to solve it...

#define SafeLT(X, Y) \
({ typeof (X) _X = (X); \
   typeof (Y) _Y = (Y); \
( _X < (NSInteger) 0 ? (( _Y > 0) ? YES : _X < _Y ) : ( _Y < (NSInteger) 0 ? NO : _X < _Y));})

This should work regardless of how you mix NSUInteger and NSInteger, and will ensure that the operands are evaluated at most once (for efficiency).

By way of proof of correctness:

For _X < (NSInteger) 0 to evaluate to True, _X must be NSInteger and < 0, so we check if _Y > 0. The compiler will make the correct comparison here by evaluating the type of _Y. If Y > 0 then by definition we return YES. Otherwise we know both X and Y are signed and < 0 and can compare them safely.
However, if X is either NSUInteger or > 0 then we test Y to see if it is < 0. If Y is < 0 then by definition we return NO. So now we have X is NSUInteger or NSInteger > 0 and Y is NSUInteger or NSInteger > 0. Since mixed comparisons will be promoted to NSUInteger we will have a safe conversion every time because there is no chance of underflow.

A simpler solution, however, would be to just typecast to a longer signed integer (iff your system has one):

#define EasySafeLT(X, Y) \
({ long long _X = (X); \
   long long _Y = (Y); \
   ( _X < _Y);})

Although this depends on having the larger type available so may not always be feasible.

score 0 · Answer 3 · answered Jul 17 '12 at 14:31

0

This does appear to be a case of comparing signed ints to unsigned ints. Your log statements will throw your assumptions because you are asking for the numbers to be printed signed.

NSLog(@"%d", -1); //Signed

-1;

NSLog(@"%u", -1); //Unsigned (tested on ios, 32 bit ints)

4294967295;

And then when you compare: 0 < 4294967295 certainly is true.

Casting as @ctrahey suggests should fix your problem:

if([self.selectedSetpoint row] < ( (int)[self.theCategories count] -3 ))
{
    //Do true stuff
}

answered Jul 17 '12 at 14:31

James Webster

31,873
11
70
114

Thanks for the information about the log throwing me off. You were a smidge late though to get the check! – Justin Paulson Jul 17 '12 at 14:44
I know! I was writing the answer as I saw the other one come through. I only continued because of the extra information about NSLog. =] – James Webster Jul 17 '12 at 14:56

score 0 · Answer 4 · answered Jul 17 '12 at 14:33

the problem is the count property is kind of NSUInteger and when you subtract a higher number from a smaller you won't get a less than zero number, you will get a very large positive number, it cause the strange behaviour.

try this way, and you would get the good result:

NSLog(@"%@",(NSInteger)[self.selectedSetpoint row] < ((NSInteger)[self.theCategories count]-3)?@"Yes":@"No");

Negative Integer Comparisons

4 Answers4