Yes, that was the problem!!
for b in 0 .. <Kn*bprg: seg[b] = 0 vs for b in 0 .. <(Kn*bprg): seg[b] = 0
I was half right, it wasn't memory management (directly) but it damn sure was
subtle.
This makes perfectly good sense now. The **seg** array wasn't being completely
cleared for each segment slice, so bits set from previous slices were still set.
Actually, I'm glad it was this than a real compiler error, because as comments
have stated, maybe this style of operators can be changed, and/or parsing the
semantics can either follow C++, or throw an error.
It now makes me wonder what did the parser/compiler do with the multiplication
by **bprg** since it didn't apply the multiplication value as the iteration
max? So there also seems to be the issue of why this didn't throw an error for
the extraneous part of the expression that seemingly wasn't applied?
But a very **Big Thanks to Jehan** for finding this. I was at my wits end.
