How long was *that* there, I wonder?

[mskala at ansuz dot sooke dot bc dot ca]

So, after a *lot* of debugging I managed to track down the source of a lot
of my problems with the IMF code.  You know what it was?

set_image_pixel_at.  It's a low-level function used throughout the IMF
code.  It basically just lets you index into bitmaps.  I've been seeing
calls to it all over the place, and writing some, and skipping over it in
the debugger, because I thought it was obvious what it did.  You call it
with coordinates and a parameter 1 to set a bit, and you call it with
coordinates and a parameter 0 to clear a bit.  Right?

Turns out that it actually does a bitwise OR.  So if you try to clear to 0
a bit that's already set to 1, nothing happens.  It appears that the code
prior to my work on it only ever used set_image_pixel_at when the input
happened to have been initialized to all zeroes, so this behaviour worked.
My code tries to use it to make changes in already-loaded bitmaps, and
then it fails.  It appears *intended* to replace the existing value
whatever it might be, and that's certainly the behaviour I would like for
my own use.  I changed it to do that (the function is local to imf.c, so I
think any unintended side effects of changing it will be easy to contain)
and all of a sudden a whole lot of my own code behaves a whole lot more
like what I expected.  Now I have to go through and un-do all the
elaborate changes I made while I was chasing this bug through other parts
of the code.  I think I'll include this patch as part of one of my bigger
ones rather than trying to submit it independently; although I think the
existing code is buggy, the bug doesn't show up except when my code
tickles it.

I'm not sure of the moral of the story - maybe "It's a good idea to trace
down into those low-level functions once in a while".  For such a simple
bug, this one soaked up a lot of debugging hours.
-- 
Matthew Skala
mskala@ansuz.sooke.bc.ca                    Embrace and defend.
http://ansuz.sooke.bc.ca/