[crossfire] Crossfire server code cleanup/janitorial

[Mark Wedel]

On 04/21/14 04:18 PM, Kevin Zheng wrote:
> On 04/21/2014 04:20, Tolga Dalman wrote:

>> 1. Define clear requirements for the crossfire server code (this
>> might apply to the client as well). From this thread, I found out
>> that the major platforms are Linux, BSD, MacOS X, Solaris, and Win32.
>> What I'm still missing is the versions. Something like this would be
>> nice: - For Linux I would just define the use of GCC 4.6 or higher,
>> binutils 2.20 or higher, glibc 2.16 or higher. - For Win32 I would
>> require Visual Studio 12 or higher - ... Naturally, these
>> requirements should be testable by the developers. Practically, these
>> items are added in the README file and perhaps published on the
>> crossfire web site.
>
> The problem with drawing a bright line is that somebody is inevitably
> left on the other side. Many working groups have drawn a standard called
> C99; we do not have to rigidly adhere to it, but instead of requiring
> specific versions of a specific toolchain, we should write portable code
> reasonably within a particular standard.

  And to follow that, if there are features of a specific version of the 
language that would be useful, say the requirement is 'the compile you use must 
support foo.  foo is known to be supported in gcc x, visual studio y, ..  If 
your compiler is not listed, see if that option is supported if additional 
compiler flags are needed'

  That in many ways works better - oftentimes, compilers will lack full support 
for certain options, but support the ones we care about.

>
>> 2. With the platform requirements above given, C99 and/or C++11 can
>> be assumed. Even if we decide not to use any C++ at all, I would
>> suggest compile the code with a C++ compiler for reasons of
>> portability.
>
> I've seen recommendations to compile C using a C++ compiler. However, if
> you refer to Bjarne Stroustrup's authoritative book he admits that
> certain incompatibilities exist. C++ is no more standard than C, and C
> is just as (maybe even more) portable as C++.

  The other problem I think that can lead to is this - suppose some change is 
made that works fine when compiled in C mode but fails in C++ mode for whatever 
reason - you now get the problem of whether the developer making the change will 
actually care about that, and depending on where that incompatibility is, 
whether they can actually figure it out if they are a pure C programmer.

  If anything, for full compatibility, compiling with different compilers with 
full warnings/strict mode may be better.

>
>> 3. With defined platform and compilers, cleanup and janitorial work
>> can start. This includes, e.g., the use of standard types (like bool
>> or uint32_t), standard functions (like calloc), removal of various
>> autoconf checks, etc.
>
> I'm in favor of doing this in the mid-term. We already have a nice
> collection of compatability macros that can serve as a crutch for
> compilers we do not obey C99.

  And that can certainly be extended.  The addition of functions like snprintf 
are worth supporting (as are strlcat and strlcpy if those are part of some 
standard), but those can also be easily checked for in autoconf, and if they 
fail to exist, some simple conditionals can check for that and private functions 
added.  Same for fixed sized types - the native types used by the compiler can 
be used instead of the typedefs currently in place, but if those native types 
are not available (due to old version), a simple enough ifdef to use the typdef 
instead.

  Other parts are harder - changes in actual syntax can't really be handled in 
that way, but I think there are few of those.

>
>> 4. Modernize architecture and replace existing components.
>
> I'm not exactly sure what this means. I also see no point in replacing
> components that have been in service and aren't breaking. I see no harm
> in rewriting code, but it'd be a lot more productive to focus on making
> the game more fun than fixing what isn't broken.

  I'd note that a lot of the goofy, ugly, or odd code exists because maps expect 
it that way.  Which is to say, some functions could potentially be made cleaner 
and simpler, but to do so would require examining every map and making changes 
to some number (and depending on exactly what construct is being used, being 
able to detect those automatically might be hard).

  I'm all for fixing some of that, but it falls into the category of a lot of 
work with no direct/end user effect.  For programmers, there is cleaner code, 
but for players, things worked (or should work) exactly the same as before.  So 
those types of changes tend to be somewhat low priority just for that reason.