================
@@ -582,6 +582,15 @@ static void visitFunctionCallArguments(IndirectLocalPath
&Path, Expr *Call,
// Temp().ptr; // Here ptr might not dangle.
if (isa<MemberExpr>(Arg->IgnoreImpCasts()))
return;
+ // Avoid false positives when the object is constructed from a conditional
+ // operator argument. A common case is:
+ // // 'ptr' might not be owned by the Owner object.
+ // std::string_view s = cond() ? Owner().ptr : sv;
----------------
hokein wrote:
> I am a bit confused to be honest. Are there any other contexts where
> `Owner().ptr` is problematic? I'd expect our analysis to behave the same for
> a subexpression like that regardless the context. So I am surprised we need
> to insert special logic for the ternary operator.
Possibly, but I don’t know of any concrete examples (it’s hard to judge). We
have another ad-hoc filter at the end, `IsGslPtrValueFromGslTempOwner`, which
filters out cases where the GSL pointer doesn’t originate from a GSL owner.
This works well for simple and common cases, but when combined with
`lifetimebound`, the behavior becomes tricky.
The current fix extends the `MemberExpr` logic (L583) to handle cases like
`GSLPointer pointer(Owner().ptr);`, but it doesn’t yet address cases like
`GSLPointer pointer(Cond ? Owner().ptr : GSLPointer());`. I think this fix is a
reasonable extension to address the issue.
https://github.com/llvm/llvm-project/pull/120233
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
