+- **Walking-pointer base reveals true struct layout.** When iterating an array of structs inside a member, MSVC 6.0 /O2 emits `lea <reg>, [this + K]` to seed the walking pointer, where `K` is the byte offset from `this` to the **center of the struct's hottest access region** — typically the middle of the first triplet of member accesses inside the loop body. If reccmp shows the original's seed is `[ebp + K0]` and yours is `[ebp + K0 + Δ]` (with every subsequent `[reg+disp]` also shifted by `Δ`), the *struct base* in your declaration is wrong by `Δ` bytes: the true struct starts `Δ` bytes earlier (or later) than you've declared, with corresponding shifts to every member offset. Example: a pointer array accessed at indices `{0, 1, 2, 9, 10, 11}` — MSVC centers the walking pointer at `&array[1]`. If that lands at absolute address `slot_base + 32`, the array starts at `slot_base + 28` (matches a declaration where ptrs begin at struct offset 28). But if MSVC's center is 4 bytes higher than the original's, the true layout has the ptr array starting at struct offset 32, not 28 — meaning there are 4 more "header" bytes before the flag than you thought, and the array's containing member starts 4 bytes earlier in the outer class. This is often the only way to pin down the struct's origin when no other function exposes the pre-flag bytes: **the displacement delta IS the struct-boundary correction**. Shift your outer-class array declaration backward by `Δ` and pad each struct's head with `Δ` extra `undefined` bytes to restore size.
0 commit comments