On Jun 23, 2013, at 22:38 , Matthew Dempsky <[email protected]> wrote:
> On Sun, Jun 23, 2013 at 3:32 PM, Jordan Rose <[email protected]> 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 _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
