Some more for consideration.

[ijbranch]

upstream-report-2026-08-27.md

[nrodear]

Re: one defect in the K2 parser fix, and one question

Thanks - both points landed, and the second one turned out to be more
than a question.

1. Position drift: confirmed, fixed

You are right, and the fix is the one you made: a separate token inside
the loop, so T keeps pointing at the declaration start.

The part worth more than the fix is your last paragraph. Our tests
assert on findings, and the finding was unchanged - only its anchor
moved, so nothing went red. We have added a test that asserts the LINE
of the two nkLocalVar nodes instead
(VarNameList_WithContextKeyword_KeepsOwnLine). That kind of test was
missing here.

Whether the drift surfaced as a finding we have not measured yet - your
reasoning about IsVarDeclLine is plausible either way. The next corpus
run will tell; we will report the number rather than guess it.

2. Read allowlist: yes, and it has already produced findings here

Answer to your question: yes. IsReadOnlyCall compares the name only -
ExtractCallFunctionName strips the qualifier and never looks at the
arguments - and the name match wins in all four paths that could set a
write (AST statement call, AST expression call, source-side pessimistic
write, same-file signature index). For a call into another unit the
same-file index has nothing to say, exactly as you describe.

It is not hypothetical on our side either. Our 2026-08-19 corpus run
carries two error-tier findings produced by this mechanism -
JclSysUtils.pas:2441 and :2574, both "FirstDigitPos is read but
never assigned". Those are same-file overloads, so the overload merge
closed them; they are gone in today's run (SCA166 30 -> 22). The
cross-unit half is still open.

We are NOT adding the arity gate, and the reason may be useful to you
rather than a disagreement:

• The trap set is larger than the arity question. In our corpus 63
  routine declarations carry an allowlist name AND a var/out parameter.
  An arity gate catches 15 of them - the other 48 have the SAME arity
  as the RTL form.
• write/writeln are variadic, so there is no number to compare
  against for those entries.
• The risk sits in the table, not in the direction. We re-ran the scan
  with deliberately too-low RTL arities (Copy=2, StrToIntDef=1,
  IntToHex=1) and it matched 7,446 sites instead of 28. One wrong
  number turns legitimate value reads into pessimistic writes - silent
  false negatives.
• Cross-unit FP candidates in our corpus today: 0.

For your fork the calculus is different: without the same-file index the
allowlist is the only thing standing there, so gating on argument count
buys you the same-file cases we get from the index. That looks like the
right call in your situation.

The proper fix on our side is a cross-unit signature index, which is the
same piece of work our memory-leak rule is waiting on. Until then the
situation is written down in the header of the list, in the style of the
identtoint note - thank you for the nudge; the same reasoning is what
made us write that one down.

[ijbranch]

Tks. My fork updated as/where applicable.