x/mobile: app.pump() will eventually crash

[db47h]

The i and j counters are never reset if the buffer is never expanded and will eventually reach MAXINT. This may seem overzealous since on a 32 bits system, this can take from a couple of months to over a year depending on the amount of events. Some applications like public information screens can however be expected to run for longer than that.

[crawshaw]

That's fair. Note to anyone who wants to fix this: there's a second copy of the code in x/exp/shiny/driver/internal/pump/pump.go. Ideally we would start by fixing that, and then copying that code over as x/mobile/internal/pump/pump.go, so that it's easier to keep them in sync in the future.

[db47h]

Sorry, I know this is border line OCD, I'll submit a CL. Regarding the fix, does anyone have a better idea than the obvious

    // ...
    // Allocate a bigger buffer if necessary.
    if i+len(buf) == j {
        // ...
    }
    buf[j&mask] = e
    j++
    if j == int(^uint(0)>>1) {
        i, j = i&mask, j-i+(i&mask)
    }
}

?

[crawshaw]

Most of the modulo arithmetic survives through overflow. The only part I haven't thought through carefully is i+len(buf) == j.

Can you first construct some example values where this code fails?

[db47h]

Woops, forget it, I got modulo (%) mixed up with the fast modulo performed with & mask. It works. i + len(buf) == j also works if only j has overflowed.