jkorous added inline comments.
================
Comment at: clang/lib/Analysis/UnsafeBufferUsage.cpp:703
+ case Strategy::Kind::Span:
+ return FixItList{};
+ case Strategy::Kind::Wontfix:
----------------
jkorous wrote:
> jkorous wrote:
> > I am afraid I might have found one more problem :(
> > I believe that for `span` strategy we have to make sure the index is > 0.
> > Otherwise
> > That means either an unsigned integer or signed or unsigned literal that is
> > greater than 0.
> > For the literal you can take inspiration here:
> > https://reviews.llvm.org/D142795
> >
> @ziqingluo-90 Sorry, looks like I wasn't clear here.
> One case (that you've already addressed) is `ptr[-5]` - for that we can't use
> `std::span::operator[]` as it would immediately trap.
> But there's the other case of:
> ```
> uint8_t foo(uint8_t *ptr, int idx) {
> return ptr[idx]
> }
> ```
> If anyone uses a value that's both signed and not a compile-time constant
> then our compile-time analysis can not prove that the index is always >= 0
> and consequently we can't use `std::span::operator[]` as a replacement.
> That's why I think we really need to make sure that the index is ether a)
> positive literal or b) unsigned.
> WDYT?
>
>
And yes ... I was wrong - literal `0` is totally fine. Thanks for spotting that!
================
Comment at: clang/lib/Analysis/UnsafeBufferUsage.cpp:894
+ if (VD->getType()->isPointerType())
+ return fixVariableWithSpan(VD, Tracker, Ctx, Handler);
+ return {};
----------------
NoQ wrote:
> jkorous wrote:
> > I believe we should add another condition here: `VD->isLocalVarDecl()` as
> > we don't support globals (yet?).
> > We run the matcher with `any_ds` tag only on function bodies so we won't
> > discover globals anyway and the `assert(It != Defs.end() && "Definition
> > never discovered!");` would fail.
> I think this check should happen much earlier. Like, we shouldn't define a
> strategy for globals, and we shouldn't build fixables out of them. And then
> `assert()` here, just to double-check.
Fair enough, we can do that. Maybe a follow-up patch?
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D139737/new/
https://reviews.llvm.org/D139737
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
