================
@@ -2516,6 +2518,47 @@ void CStringChecker::evalSprintfCommon(CheckerContext
&C, const CallEvent &Call,
C.addTransition(State);
}
+void CStringChecker::evalGetentropy(CheckerContext &C,
+ const CallEvent &Call) const {
+ DestinationArgExpr Buffer = {{Call.getArgExpr(0), 0}};
+ SizeArgExpr Size = {{Call.getArgExpr(1), 1}};
+ ProgramStateRef State = C.getState();
+ constexpr int BufferMaxSize = 256;
+
+ SVal SizeVal = C.getSVal(Size.Expression);
+ QualType SizeTy = Size.Expression->getType();
+
+ ProgramStateRef StateZeroSize, StateNonZeroSize;
+ std::tie(StateZeroSize, StateNonZeroSize) =
+ assumeZero(C, State, SizeVal, SizeTy);
----------------
NagyDonat wrote:
Yes, if the current code encounters a situation when the size may be zero _and_
may be nonzero (so `assumeZero` splits the state and returns two non-null state
references), then it will act as if the size argument was _known to be_ zero
and transitions to a state where the return value is _known to be_ zero.
You need to explicitly handle this ambiguous case somehow:
(1) either you do a state split and create two separate transitions to the two
possible branches (and create note tags that e.g. say "assuming the 'size'
argument is zero" on the branch where you assume that)
(2) or, alternatively, you keep a single transition and try to ensure that the
potentially affected values are marked as unknown (e.g. don't bind a value to
the call expression and probably you should invalidate the buffer contents).
https://github.com/llvm/llvm-project/pull/83675
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
