@pfultz2 Any comments?

I dont think this is a good idea. This just completely bypasses using the ProgramMemory to evaluate the container sizes.

Also adding asserts should prevent FPs not introduce FPs as well.

The fix prevents mixing values from different containers (o and v in the example). Why would checking match() be wrong here?

Adding the assert() seems to suppress a FP, but probably for the wrong reasons. There is still something else going wrong, see #10322.

Why would checking match() be wrong here?

It bypasses using ProgramMemory to evaluate container sizes which come from other assumptions. It also only will evaluate a container size when you are forwarding a container size as well.

Adding the assert() seems to suppress a FP, but probably for the wrong reasons.

No is not for the wrong reasons. It works because we assume the assert is true:

https://github.com/danmar/cppcheck/blob/main/lib/forwardanalyzer.cpp#L805

This allows users to add asserts to reduce FPs. With this change, it is no longer possible since we wont use ProgramMemory to evaluate container sizes.

Also, this issue seems like there is a problem with fillProgramMemoryFromAssignments. We know v is empty so it seems like when it sees o = v it set o to empty as well, but shouldn't since there was a v.clear().

There is still something else going wrong, see #10322.

That is a seperate issue. I think we need a stopOnForRangeLoop similar to stopOnCondition. Since the value is already conditional, we need to be conservative about proceeding.

Also, this issue seems like there is a problem with fillProgramMemoryFromAssignments. We know v is empty so it seems like when it sees o = v it set o to empty as well, but shouldn't since there was a v.clear().

Yeah, I don't understand what's going on in fillProgramMemoryFromAssignments(). We start at clear with an empty v, but then go backwards and add an empty o value. There's origins, but it's not set or checked at that point.