[perfloop-agent]

Reusing a nonzero Decimal destination no longer changes the zero count returned by Reduce for a finite zero operand.

Only the returned count of removed zeros is wrong; the reduced Decimal value is already correct. Within apd, Context.Reduce and ErrDecimal.Reduce pass the count on unchanged.

Fix

The zero branch now reads the operand's digit count before resetting the destination. The reused-destination subtests fail on master with got 1 zeros removed; master reads the destination at line 719 in decimal.go.

This overlaps #165: its open diff still reads d.NumDigits() in the same zero branch, so whichever merges second needs a one-line rebase. #166 sums counts from two Reduce calls (n + m); its first count depends on this correction for a reused zero destination.

Tests

TestReduce in decimal_test.go covers 0, 0E+3, and 000 with a New(10, 0) destination. It checks the returned count and reduced zero value.

go test -run '^TestReduce$' -count=1 .

Reuse prevalence and downstream impact remain unmeasured.

Case and evidence

---

Generated by Perfloop. Human sponsor: Tomás Senart.

[tsenart]

Hi, I'm Tomás, I build Perfloop. I approved this contribution and will handle review feedback here.

We found this bug while developing Perfloop's auto-formalization capabilities. We've had changes merged in Dolt, ClickHouse, Redis, Prometheus, RoaringBitmap, and more.

If you'd like anything in this patch changed, just let me know and I'll update it.