[CF-Devel] More patches and things to consider

[crossfire-devel at archives.real-time.com]

>
     
     Argh! Void pointers!
     
     
>
     
        Last time I looked there's a couple of places in the Python plugin that possibly assume ints and longs were passed by reference rather than by value, causing '*(int *)' to have unexpected values.
     
     
>
     
        I'm not sure which way around's the one intended by the plugin system's author, though.
     
     
Yes, void pointers. A bit of explanation is probably needed about them.

In its initial version, the plugin was simply a dynamically shared library calling the Crossfire functions directly. This wasn't working on a couple of implementations, because functions from the 'common' part ended out-of-context (the plugin and the server accessed two different 'copies' of those, resulting in bad results).

The solution was to provide wrappers to those functions from the server context itself (I admit it, it is not the most elegant solution - I'd have scrapped the whole common/server split away myself, but I'm not the only one to decide such drastical changes). That's what you can find in server/plugins.c and include/plugin.h.
Because of the dynamical binding requirements, it was easier and cleaner to export only one function prototype for all wrappers: it gets one CFParm* as parameter, and returns one CFParm* as a result. And since it had to hold various data types, CFParm.Value is defined as an array of void*. Most void* data conversions made in the plugin context belong to that category. The same holds true for the event calls.

Another common occurence of a strange typecasting in the plugin may be found when passing game objects from/to the plugin. This was simply to avoid the need of custom types handling in the Python interface - by wrapping pointers into long values, PyArg_ParseTuple() could be used directly without the need of further code. Admittedly, this is fundamentally unclean programming - but it worked in a way that was compatible with both 32 and 64-bit architectures. The Python plugin itself isn't supposed to modify that value manually - it should always rely on the internal functions of the server to manage objects.

It is now very well possible that mistakes were made in some places between references and values; if you give me pointers to the problematic section(s) of the code, it would be a pleasure to correct them.


_______________________________________________
crossfire-devel mailing list
     
     crossfire-devel at lists.real-time.com
     
     
     https://mailman.real-time.com/mailman/listinfo/crossfire-devel