Yes, the way it handles the copy is a bit obscure. But removing those 3 lines is not the solution.
I'm shooting blind, but if there is truly corruption, it's very likely the code should then look like:
Code: Select all
*pDstRea = tmp.x;
*(pDstReal+1) = tmp.y;
*(pDstReal+2) = tmp.z;
While that will also fix the problem, it will still fall through and do the copy twice. I would punt that AshMcConnell is victim of an unrelated issue.
That being said it is a clear buffer overrun, and removing the 3 lines does indeed fix it. The buffers are the correct size.
Lets simplify this.
Assume a buffer with one vert and that vert only has a position therefore the two buffers (the source and the destination ) are 12 bytes.
The switch will be hit once.
The position gets set once like this
Code: Select all
//pDstReal is pointing to byte 0 here
*pDstReal++ = tmp.x;
// pDstReal is pointing to byte 4 here
*pDstReal++ = tmp.y;
// pDstReal is pointing to byte 8 here
*pDstReal++ = tmp.z;
// pDstReal is pointing to byte 12 here which is 1 byte past where this iteration of the loop should ever access.
// the switch then falls through to the default case and does this. (the 12 for simplicity)
memcpy(pDstReal, pSrcReal, 12 );
Clearly it is reading 12 bytes past the end of one buffer and writing 12 bytes past the end of the other.
The reason removing the 3 lines works is because then then memcpy does the exact same thing as they would have.
It can also be fixed by adding a break before the default case. The only reason I didn't opt for that solution is that i much prefer removing 3 lines of code to fix a bug rather than adding 1. lol.
This is also why your solution works, because it doesn't change the pointer so the memcpy doesn't overrun, but it still ends up doing a copy twice.