Bugzilla

This was caused by attachment 8764294 [details] [diff] [review]. When the loop is exited early if the polygon has no more points, then the calculation `size_t srcPointCount = dstPoint - points[0];` outside of the loop can be wrong: `&points[0][0]` is only the start of the current set of polygon points if the current plane index is even. When it is odd, the current set of polygon points starts at `&points[1][0]`.
Or in other words, this function does some double buffering and then assumes one of the buffers is in use when the loop is exited, but due to early exits it can be the other buffer that's currently in use.

This was caused by attachment 8764294 [details] [diff] [review]. When the loop is exited early if the polygon has no more points, then the calculation `size_t srcPointCount = dstPoint - points[0];` outside of the loop can be wrong: `&points[0][0]` is only the start of the current set of polygon points if the index of the most recently-applied plane is odd. If that index is even, the current set of polygon points starts at `&points[1][0]`.
Or in other words, this function does some double buffering and then assumes one of the buffers is in use when the loop is exited, but due to early exits it can be the other buffer that's currently in use.

This was caused by attachment 8764294 [details] [diff] [review]. When the loop is exited early if the polygon has no more points, then the calculation `size_t srcPointCount = dstPoint - points[0];` outside of the loop can be wrong: `&points[0][0]` is only the start of the current set of polygon points if the index of the most recently-applied clipping plane is odd (1 or 3). If that index is even (0 or 2), the current set of polygon points starts at `&points[1][0]`.
Or in other words, this function does some double buffering and then assumes one of the buffers is in use when the loop is exited, but due to early exits it can be the other buffer that's currently in use.