[Again, since it's not clear if the mail-index.netbsd.org problem with
 lost mail is fixed---much less if it will "stay" fixed---please include
 me in the To: or Cc: line of any replies.  Thanks.]

I recently posted asking for help with a GLUT/C++ problem and a class
library that I've started to toy with.  The bug was (still is) that
when you spin the mouse wheel, the program often crashes.  Although no
one has replied, I have been able to find out a bit more, and it suggests
either a bug, or a subtle weirdness, about the C compiler.

The bug still happens.  The crash behaves differently if I permute some
of the invocation code.  It mostly only happens if I spin the mouse wheel
in one direction, not the other.  The crash is within GLUT.  The
class library is using member functions (static, of course) for callbacks
(function pointers) for the GLUT to use.

The problem does not seem to strike if I use plain (non-member) functions.

Yes, I am aware that wheel-buttons are supposed to look just like more
mouse buttons.  Yes, regular mouse-buttons seem to always work.  (I guess
I haven't tried hooking up my 5-button trackball to see if there might
be something magic about the button numbers & GLUT...)

I didn't know if it was some subtle stupidity on my part or not, and
was finding it frustrating to try to trace the GLUT's execution, since
it builds from pkgsrc and I can't seem to get a version with suitable
debugging info.  (This was the content of my previous question.
Any help with that would still be appreciated, though I may try asking on
tech-pkg in a day or so, and see if anyone over there has any suggestions
for debugging a shared library.)


HOWEVER, I did try another tack: I took the GLUI (another GLUT-based
GUI library, this one LGPLed), and saw if I could recreate the crash under
GLUI.

I can.  Very similar behavior (though instead of being 1, sometimes both,
scroll-wheel directions to crash, it is: Sometimes both do NOT crash,
and ONE direction seems to always be safe).  The slight variation is
somewhat consistant with some other observations that the crash varies
if I permute some of the code, suggesting that it depeends upon
alignment, or addrersses, of bits and pieces of the running program.


Is this considered a known bug?  I thought that *static* member functions
could have their addresses taken just like "real" functions.

It appears that I was wrong, and that pointers to static member functions
are not the same as pointers to functions.

Or should I file a pr?  Or is there something about C++ that makes it
meaningless to try to pass even a static member function pointer to a
C function?  (It *does* work most of the time, and it's really bizarre that
it matters which "button" X is returning!  Then again, the X server is
returning two mouse buttons (down, then up) in quick succession, so maybe
the GLUT is just not smart enough to handle that, not believing that a real
button could be pressed & released so fast?  But, again, this is NOT a problem
if I use a non-member function...I can spin the mouse wheel all day if I
register a regular function for mouse callbacks with the GLUT.)

Is this bug likely to go away with GCC 3.x?

(I don't at the moment have any other systems set up to compare with.
E.g., GNU/LINUX, etc.)


Thanks in advance.


-- 
  "I probably don't know what I'm talking about."  http://www.olib.org/~rkr/