martong added a comment.

> Is really more kind of constraint needed than range constraint?

Yes, there are other constraints I am planning to implement:

- Size requirements E.g.: asctime_s(char *buf, rsize_t bufsz, const struct tm 
*time_ptr); `buf` size must be at least `bufsz`.
- Not-null
- Not-uninitalized
- Not-tainted

> A non-null can be represented as range constraint too.

Actually, to implement that we should have a branch in all `ValueRange::apply*` 
functions that handles `Loc` SVals. Unfortunately, a pointer cannot be handled 
as `NonLoc`, and the current Range based implementation handles `NonLoc`s only.

> The compare constraint is used only for the return value for which a special 
> `ReturnConstraint` can be used to handle the return value not like a normal 
> argument (and then the `Ret` special value is not needed).

The Compare constraint is already forced into a Range "concept" whereas it has 
nothing to do with ranges. By handling compare constraints separately, we 
attach a single responsibility to each constraint class, instead of having a 
monolithic god constraint class. Take a look at this coerced data 
representation that we have today in ValueRange:

  BinaryOperator::Opcode getOpcode() const {
    assert(Kind == ComparesToArgument);
    assert(Args.size() == 1);
    BinaryOperator::Opcode Op =
        static_cast<BinaryOperator::Opcode>(Args[0].first);
    assert(BinaryOperator::isComparisonOp(Op) &&
           "Only comparison ops are supported for ComparesToArgument");
    return Op;
  }

Subclasses are a good way to get rid of this not-so-intuitive structure and 
assertions.

> Or are there sometimes relations between arguments of a function?

I can't recall now a direct relation by heart.
But there could be more subtle indirect relations, see the size requirements 
above. (Thought I'd rather implement that in a separate constraint class.)


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D74973/new/

https://reviews.llvm.org/D74973



_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Reply via email to