[crossfire] Crossfire server code cleanup/janitorial

Kevin Zheng kevinz5000 at gmail.com
Wed Apr 23 14:12:10 CDT 2014


On 04/23/2014 01:43, Mark Wedel wrote:
> My idea if using new functions provided by libraries (if they exist) 
> and include local copies if they don't is that often times vendor 
> provided functions may be much better optimized that locally
> included ones.

Agreed, even if the speed improvement is negligible.

> Also, for some functions (like strlcpy), it may be a trivial exercise
> to include a local copy of equivalent functionality.  But for others,
> like snprintf, it might be hard, but a simple replacement of non
> equivalent functionality is easy, like:
> 
> sprintf(buf, ...) if strlen(buf) > buflen { oops, we have a buffer 
> overrun }
> 
> which isn't great, but could still be better than an alternative of 
> just using an unprotected sprintf.

It's probably a good idea to maintain local copies of non-standard
functions, but I think things like "snprintf" are safe to use anywhere
(even in Visual Studio).

> I will also note that crossfire actually does a fair amount of 
> floating point - all the speed and speed_left is floating point, the 
> just simple addition/subtraction.

Yes, but C99 brought additional functions and macros to control the
precision of floating point operations. Neither GCC nor Clang support
that part of the standard, but we don't care much since the existing
operations are good enough.

Floating point operations in C89 are still here, don't worry :p

> The plugin logic has pluses and minuses - the ability to right 
> plugins that register themselves is good, but the entire dynamic 
> loading adds a bit of code complexity and another place for errors. 
> But also, at one time, the python plugin was optional, so you could 
> run the server without necessarily having python & its development 
> libraries installed.  But IIRC, at some point, it was decided that 
> enough scripts and other stuff require python it should become 
> standard - since it is known it will always exist, whether having it 
> be a dynamically library that is loaded makes sense is debatable.

I like the idea of conditionally compiling required "modules". We don't
seem to have a lot of third parties who want to make plugins, and it
adds a layer of abstraction that recently caused subtle problems.

I am *not* volunteering to swoop in and rip them all out, though :D

Thanks,
Kevin Zheng


More information about the crossfire mailing list