I just posted a patch to the SF bugtracker, but then I saw it's infrequently visited by devels: http://sourceforge.net/tracker/index.ph ... tid=575114
It fixes the issue from topic http://www.scorched3d.co.uk/phpBB2/viewtopic.php?t=4705
I've also noticed a graphics bug, but my patch does not fix that.

By the way, is there a mailing-list where I can post patches/fixes/bugreports? Or just this forum?

Hi Eduard,

Thanks for the patch, you are correct I/we don't look at the bugtracker too much.

The va_list is a nice find, however I think the other user data fixes are incorrect and will not work as intended.

e.g. the fix (and others) are like this

- int type = int(entry->getUserData());
+ int type = *((int *) entry->getUserData());

However the userdata is (contains) the int value, and is not a pointer to an int value. So the original is correct not the patch!

userdata is a pointer to void:

However, let's assume you do store an int value in this pointer. But then the interface is inconsistent, as there are places where userData_ is used as I predicted:

The class referred to in the patch contains setUserData() as a method to set userData_. But this method isn't called anywhere.

I couldn't find a line of code which sets userData_ for this one, but maybe I didn't try hard enough.

It think the bug goes unnoticed at runtime because that functionality is not fully implemented yes.[/code]

Yes, thats how I wrote it.



Is the interface inconsistent or is the understanding?
Yes, there are places that use it as a pointer, but these places in your patch are not such places. The patch is incorrect.



It can also be set via the constructor as it is in this case.



Err, no it is used and it works!

PS applied va_list stuff to CVS.

All right, then what's left to do is to prevent gcc from spitting out errors (build fails on AMD64 because sizeof(void *) != sizeof(int)). See the patch fix-build_on_amd64.patch from http://sourceforge.net/tracker/index.ph ... tid=575114

If I came up with a better (i.e.: unified) approach to using userData_, would you consider merging the changes? I'm thinking of having setUserData() clone the object (as in allocating memory for it) and storing a pointer to it in userData_; or something similar. Why? getUserData() is a public method and everybody should end up with the same type of object.

Response to P.S.: What about the push_back() stuff? I'm not a C++/STL expert, but this works for me, as opposed to append(). Seems more natural, too.
Edit: I see that one was merged too. I should've checked before bugging you.

The 64bit compile issues you mention I patched from this post:
http://www.scorched3d.co.uk/phpBB2/viewtopic.php?t=4705
So they should be fixed now too.

Yes I added the STL string stuff too.

I am not sure what issue you have with the userdata, it is as the name suggests data that is only applicable to the caller of the API (the user). When the user makes the first call they get to pass in some user data, this data is then returned to them during any async callbacks.
Since the user is the once providing the initial data they will know what to expect in the callback and cast it correctly. It's a common pattern.

Although it works in this situation, it may be wrong, as a long may still be shorter than a pointer. I suggest using an opaque data type such as intptr_t, but maybe I'm being pedantic. See the following links:
http://archive.opengroup.org/public/tec ... p64_wp.htm
http://en.wikipedia.org/wiki/C_variable ... tions#Size