It *is* a code bug, not a compiler bug. It's tricky though:
numset_find_empty_cell realloc's numbers taken... *which can cause it
to move*. So the original assignment would then be writing into the
old memory address, if it looks up ns->numbers_taken before the call
and then makes the call and then does the assignment... what made me
see this was printing out the numset and seeing it go from 0 1 2 3 4 5
6 7 8 9 to 0 1 2 3 4 5 6 7 8 9 65529, when the assignment clearly
*should* have been happenning.
So, this might be *masked* on some platforms by compiler differences
(though I'd have to dig into the ANSI spec and reread the stuff on
sequence points to convince me the compiler's allowed to do it both
ways - I *suspect* that any compiler that does the lookup after the
call (such that it doesn't show the problem) actually has a bug.)
This is a great little tricky bug. I'm also not sure which
compilers are right and which are wrong, but I was always under the
impression that a function is allowed to change a pointer, so
a = b[f(n)];
and
c = f(n);
a = b[c];
where equivalent; my impressions do not a standard make, however.
I'll have to try it again with numbers_taken declared as volitile.
So, does that convince you to commit the change in that form?
I'll certainly change it in my JN patch, but it's up to Shawn to change in the mainline.