public inbox for xconq7@sourceware.org
 help / color / mirror / Atom feed
* How long was *that* there, I wonder?
@ 2004-12-04  5:23 mskala
  2004-12-04 12:40 ` Eric McDonald
  0 siblings, 1 reply; 2+ messages in thread
From: mskala @ 2004-12-04  5:23 UTC (permalink / raw)
  To: xconq7, xconq-general

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/

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2004-12-04  5:23 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-12-04  5:23 How long was *that* there, I wonder? mskala
2004-12-04 12:40 ` Eric McDonald

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).