[crossfire] Crossfire server code cleanup/janitorial

Mark Wedel mwedel at sonic.net
Wed Apr 23 01:43:54 CDT 2014


Few general notes on this:

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.

  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.

  I do tend to agree with the comment that given crossfire is C code, using a C 
compiler would seem to be the best tool to use to compile it.  That said, if it 
happens to compile with a C++ compiler, or changes are trivial to let it do so, 
great.  But I'd just put the responsibility of making sure it compile with C++ 
belongs to those who want to compile with C++, not all developers.

  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.

  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.





More information about the crossfire mailing list