best weird debugging experience ever

I am captivated by each nugget of horrible code.

typedef struct RMAP
{
bill* pbill;
line* pline;
rule* prule;
} rmap;

I'm not sure what I find the most interesting... The fact that somebody thought it was fine to copy that struct definition throughout 15+ .c files.

Or, the fact that somebody slightly modified a couple of those instances.

typedef struct RMAP
{
bill* pbill;
line* pline;
rule* prule;
Bool overrideFlg;
} rmap;

typedef struct RMAP
{
bill* pbill;
line* pline;
rule* prule;
double accum;
} rmap;

Or... the best subtle weirdness, in one instance someone reordered the pointers.

typedef struct RMAP
{
rule* prule;
bill* pbill;
line* pline;
} rmap;

So... when you debug the following code in any of the _other_ .c files...

void myCrazyFunction(rmap* a_rmap)
{
rule* r = a_rmap->prule;
double reduction = r->reduction;
... blahblahblahblahblah ...
}

At runtime, everything works -- the definition of rmap used by the compiler is the definition within the .c file, and the third set of pointer-size bits within the a_rmap struct are assigned to 'r'.

But, when I try to debug the code in Visual Studio and hover over the a_rmap->prule I see a bunch of garbage. I hover of 'r', and I see it's got the values I expect.

I'm guessing the debugger finds the first instance of the rmap type in the .pdb file, and the one oddly ordered struct just so happens to be in the first .c file alphabetically (and also first in build order).

But, that realization doesn't come until about 2 hours of other wild goose chases through the rest of the call stack to eliminate the other 'more likely' possibilities.

Good times.