[shounakjoshi88-a11y]

Why

roaringArray.clear() did resize(0) and reset copyOnWrite = false. Bitmap.Clear() routes through it, so a bitmap the caller had put in copy-on-write mode with SetCopyOnWrite(true) silently lost that mode on Clear — and its next mutation then ran with sharing off, which is exactly what the mode exists to prevent:

rb := BitmapOf(1, 2, 3)
rb.SetCopyOnWrite(true)
rb.Clear()
fmt.Println(rb.GetCopyOnWrite()) // false — the mode is gone

The other two callers of Clear() — Xor and AndNot on a bitmap with itself (rb == x2) — route through Clear as well, and a result bitmap should keep its mode there too.

What

• roaringArray.clear() only resizes to zero; copyOnWrite is a mode the user selects, not part of the contents, so it survives Clear. It is still reverted by SetCopyOnWrite(false).
• TestClearKeepsCopyOnWrite pins it: GetCopyOnWrite() stays true after Clear on a copy-on-write bitmap (and false after Clear on one without), and the bitmap is still usable and valid after the next Add.

$ go test -run TestClearKeepsCopyOnWrite -v .
=== RUN   TestClearKeepsCopyOnWrite
--- PASS: TestClearKeepsCopyOnWrite (0.00s)
PASS
ok      github.com/RoaringBitmap/roaring/v2     4.016s

The full package is green, gofmt/go vet clean on the two touched files. The test fails on main without the one-line fix.

[shounakjoshi88-a11y]

Hi - the workflows on this pull request are waiting for approval to run (a fork pull request needs a maintainer to approve the first run). Could someone approve them when convenient?

Everything is green locally:

$ go test .
ok  	github.com/RoaringBitmap/roaring/v2	20.243s

$ go test -run TestClearKeepsCopyOnWrite -v .
=== RUN   TestClearKeepsCopyOnWrite
--- PASS: TestClearKeepsCopyOnWrite (0.00s)
PASS
ok  	github.com/RoaringBitmap/roaring/v2	4.016s

gofmt and go vet are clean on the two touched files (roaringarray.go, cow_edgecases_test.go), and the new test fails on main without the one-line change.

[lemire]

Thanks for the report. We're keeping Clear() as a full reset (copy-on-write off, as for a new bitmap), which has been the behavior since copy-on-write was introduced and also matters for bitmaps loaded with FromBuffer. We've documented this on Clear() in both packages, and fixed Xor/AndNot of a bitmap with itself so they no longer drop the copy-on-write setting. Closing in favor of #596.

[shounakjoshi88-a11y]

Understood, thanks for the explanation - Clear() as a full reset is a reasonable choice, and the FromBuffer case makes sense. I will not push this further.