Did the branching factor change break anything else apart from #491?

[sjakobi]

Given how long #491 went undetected, I wonder whether 2c8a286 has resulted in any other subtle bugs.

I can imagine raising our confidence by several methods:

• Check (and improve) the test coverage
• Run the property tests with increased --quickcheck-max-size and --quickcheck-tests (especially on 32bit systems)
• Review the code that manipulates and iterates over bitmaps
• To catch potential integer overflow bugs, is there a way to "trap" integer overflows in Haskell?

[treeowl]

There are some relevant primops, but I dunno how much we'll have to pay for them: addIntC#, subIntC#, and mulIntMayOflo#. The first two of those also have Word# equivalents.

[treeowl]

Any idea if Liquid Haskell is powerful enough to express the properties we need?

[sjakobi]

Any idea if Liquid Haskell is powerful enough to express the properties we need?

No idea 🤷‍♂️

[treeowl]

@nikivazou, what do you think?

[sjakobi]

Instead of looking for more bugs, we've gone back to maxChildren = 16 for 32-bit systems in #501.

[nikivazou]

@nikivazou, what do you think?

Yes, Liquid Haskell would be good at reasoning about such kinds of integer properties! I think it worths passing it to containers!

[treeowl]

@nikivazou , thanks. We'll have to look into that separately.