Sorry Thierry, look at the code again. nCol never goes out of range.
The case is the path through the switch. It varies from 0 to 6, but only cases 5 and 6 do anything in this version.
The column varies from 0 to 7. It never goes out of range, because the nextCol function wraps from 7 back down to 0.
I don't see any place where nCol can go beyond 7.
Don't be so quick to blame my code when the optimizer is at fault. :-)
In actual fact, I've seen optimizer bugs on several platforms over 3 years of porting code to 5 flavours of Unix. As I mentioned, the DEC Alpha optimizer, on 64 bit machines, was extremely buggy. So I have seen a variety of optimizer bugs before.
That said, I am not quick to blame the optimizer at all. It never occurred to me that this was an optimizer bug at first. My first hunch was it was an iterator invalidation problem in another area of my code. But when I saw the view display things in places they shouldn't be, I knew the problem was here (where they are created). I went over the code visually and couldn't see the problem, so I began adding log output to track it down. (I couldn't debug because I can't debug remotely and it doesn't appear in debug builds.) Once the log output removed the problem, I knew I had an optimizer error situation. I've seen it many times before.
