[PATCH] Fix SimpleSValBuilder::evalBinOpLN

[Jordan Rose]

On Jun 23, 2013, at 22:38 , Matthew Dempsky <matthew at dempsky.org> wrote:

> On Sun, Jun 23, 2013 at 3:32 PM, Jordan Rose <jordan_rose at apple.com> wrote:
>> Hi, Matthew. In pointer expressions like "p != 0", the 0 gets converted to a pointer before the comparison, so that goes through evalBinOpLL(). Do you have any solid examples where this is failing?
> 
> Sorry, no, not at the moment.  I think I was originally hitting this
> issue because I had bugs in my checker code.  Later after
> improving/fixing my checker, that evalBinOpLN() change proved no
> longer necessary, at least for my use case.
> 
> But I do still think special casing rhs.isZeroConstant() before
> checking for BinaryOperator::isComparisonOp(op) is probably a bug.
> Comparison operations should return a boolean SVal, not a pointer
> SVal.  I just don't know off hand of any legitimate use cases where
> evalBinOpLN() will be called with a comparison op.

There aren't any...all of the symmetrical operations require both arguments to be of the same type. I'm pretty sure the "Special case" below for the compare-and-swap functions is now dead code.

Do you think it'd worth adding an assertion that we never get a comparison op here?

Jordan