Re: [crossfire] Crossfire server code cleanup/janitorial
On 04/25/14 03:53 PM, Kevin Zheng wrote: On 04/24/2014 01:48, Mark Wedel wrote: Beyond that, there was a separate ticket/discussion about the need to have perl for the server on windows to collect the archetypes. To me, that isn't a big issue, but so some it is, and if that is an issue, I'd then think requiring additional libraries would fall into that extra pain. It could also make binary distributions harder I was working on that ticket but kind of dropped the ball on it. I don't see the Perl dependency as a problem, either, but I understand that it _may_ be troublesome on Windows. I am also considering moving the archetype collection scripts to the arch directory, any thoughts on this? This is sort of a messy one. It sort of seems obvious that the arch collection (and related bits) should be in the arch tree. However, it is the server that is the actual consumer of those files. So if they are collected in the arch tree, they somehow have to get into the right directory for the server to use them. Now there are certainly different ways to handle this - you could have the server call arch/scripts/collect.pl - I'm not exactly sure how that improves anything. Likewise, one could run the script in the arch directory, and if it deposit the files in arch/build or something, and then have the server install process know to look there. That actually seems more complicated. Plus, it is nice to just be able to do a 'make collect' in the lib directory and have it do the right thing. I'm not opposed to relocation of those scripts - I'd just like to see more how it will all works out. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Crossfire server code cleanup/janitorial
On 04/24/2014 01:48, Mark Wedel wrote: > Beyond that, there was a separate ticket/discussion about the need to > have perl for the server on windows to collect the archetypes. To me, > that isn't a big issue, but so some it is, and if that is an issue, I'd > then think requiring additional libraries would fall into that extra > pain. It could also make binary distributions harder I was working on that ticket but kind of dropped the ball on it. I don't see the Perl dependency as a problem, either, but I understand that it _may_ be troublesome on Windows. I am also considering moving the archetype collection scripts to the arch directory, any thoughts on this? Thanks, Kevin Zheng ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Crossfire server code cleanup/janitorial
> The standard "strncat" and "strncpy" functions do not guarantee that the > destination buffer will be null-terminated. This means that your changes > are vulnerable to many buffer overflow attacks. Yes, but then those functions are used incorrectly. If the buffer is too short, the cpy/cat operation will misbehave (i.e., the string will be truncated). > Using the sstring construct in Crossfire or moving to C++ will mitigate > this possibility, but probably not completely remove it. I agree. > Some of the code in the network loop should be cleaned up. Once I was also > considering using something similar to SDL_Net, but decided that it wasn't > worth the effort. SDL Net is a fine portable socket abstraction and might solve some immediate ugliness of the current networking code. Another possibility is to go a step further and use frameworks like MessagePack or Protobuf for serializing/deserializing byte streams and ZeroMQ as communication framework. However, two problems come with that as well: as Mark noted these libraries must be supported by all platforms, and such a change would mean a considerable amount of work with little visible effects for the user. > I noticed many changes to silence compiler warnings. I haven't taken a > closer look, but perhaps it may be a good idea to change the function > definitions themselves instead of prefixing "(void)"? That's what I did where possible. Elsewhere (esp. in types/) I couldn't easily change the API. > I also noticed a lot of changes that simply rip out compatibility in > 'porting.c', which is intended to keep that kind of stuff. Ideally, there > would be no conditional compilations except there. Assuming C99, these functions are not really needed, right ? > Extend the above mentioned issue with ripping out the safe_* functions. I haven't yet touched those, though I guess there could be done some simplification as well (i.e., use tmpfile or mkstemp instead of tempnam*). > I'll be working on cherry-picking specific changes, I hope your rebases > with master aren't too painful :) Thank you very much! I really appreciate it. > Consider using `git svn` which lets you keep track of the SVN repository. > You can also rebase your work off my pre-cloned repository and track SVN > from there. Great hint, I didn't know about that before. I'll investigate. Best regards Tolga Dalman ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Crossfire server code cleanup/janitorial
Just a quick note: While using external libraries for certain common things can be handy, one also has to be careful about how common these libraries are (eg, if it doesn't exist on certain platforms, its convenience factor goes down a whole bunch) Beyond that, there was a separate ticket/discussion about the need to have perl for the server on windows to collect the archetypes. To me, that isn't a big issue, but so some it is, and if that is an issue, I'd then think requiring additional libraries would fall into that extra pain. It could also make binary distributions harder certainly, using standard functions that are available on all systems and simplify life should be done. The socket code got a bit messy with all the WIN32 #ifdefs - a simpler solution there would probably be add a 'read_from_socket' type function which makes the appropriate call and checks the appropriate error types and returns appropriate error code, so all that logic only has to be in one function and not duplicated many times. Same could be done for the write calls. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Crossfire server code cleanup/janitorial
Compile time modules for the plugins would probably be simpler (avoids dynamic linking) I think the one notable change would be each plugin would need its own init function (init_python, init_logger, etc), and some part of the server code would have to have the #ifdefs to call those or not. The one advantage of the dynamic linking module is there is a standard/common init that is called during the loading. The idea of third party modules is hard to imagine - unlike say plugins for firefox which tend to be fairly abstract, the plugins for crossfire are really tied to the server they are compiled with. That is/was one source of many problems - a new field is added to some object, the server is recompiled, and maybe even the plugins, but the plugins are not installed so access to the structure gets random values. So I can't ever see anyone distributing a binary only .so file and have it work, unless it was very trivial. So they will always be source, and even if due to license reasons it can't be distributed as part of crossfire, it still wouldn't be hard to just make the appropriate directory in the plugins directory and add the logic for it to get compiled. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Crossfire server code cleanup/janitorial
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
___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Crossfire server code cleanup/janitorial
On 04/23/2014 02:17, Tolga Dalman wrote: > It is not only the language and the employed toolchain. In my > experience, problems begin as soon as you start implementing > containers and data structures in C (which, btw, has been done in > crossfire). It is then a good idea to use standardized library > functions, like, strings, lists, or hash tables. All this is provided > by C++ for free in a highly portable way. While using C++ means that we can reinvent less wheels, the current implementation is no less portable. >> Right now the code seems to compile fairly cleanly. > > Try compiling with gcc 4.8. While almost all issues are minor (unused > variables and signed compares), there is some work left with at least > GCC. I haven't tried other compilers though. I'm using Clang and I haven't seen warnings about unused variables. I'll poke around my compiler flags and see if I can get them. >> While strlcat and strlcpy are not defined by any standards body, I >> believe that they are superior to the normal functions and should >> be used whenever possible. If you haven't noticed, I recently >> committed a small chunk of platform-dependent code that uses these >> two functions when available instead of our hacks around it. > > Yes, and that's a good progress! However, I still fail to understand > why strlcat/strlcpy would be superior to strncat/strncpy. The standard "strncat" and "strncpy" functions do not guarantee that the destination buffer will be null-terminated. This means that your changes are vulnerable to many buffer overflow attacks. Using the sstring construct in Crossfire or moving to C++ will mitigate this possibility, but probably not completely remove it. >> Even then, some specifics would be useful. What are you suggesting >> for networking or the server loops? > > I haven't had thought about it well enough, but I can think of two > possibilities: a) refactor/rewrite the code. b) use third-party > libraries. My preference is of course b), however, such a step must > be thoroughly investigated beforehand. Some of the code in the network loop should be cleaned up. Once I was also considering using something similar to SDL_Net, but decided that it wasn't worth the effort. > I won't be able to test any other platform than Linux and I won't be > attempting to do so either. If you think some of the changes are > worthwhile to adopt, I'd be happy of course. Likewise, please don't > hesitate to comment on my patches. I will try to keep the code in > sync, but at some point that will no longer be possible. I noticed many changes to silence compiler warnings. I haven't taken a closer look, but perhaps it may be a good idea to change the function definitions themselves instead of prefixing "(void)"? I also noticed a lot of changes that simply rip out compatibility in 'porting.c', which is intended to keep that kind of stuff. Ideally, there would be no conditional compilations except there. Extend the above mentioned issue with ripping out the safe_* functions. I'll be working on cherry-picking specific changes, I hope your rebases with master aren't too painful :) Consider using `git svn` which lets you keep track of the SVN repository. You can also rebase your work off my pre-cloned repository and track SVN from there. Thanks, Kevin Zheng ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Crossfire server code cleanup/janitorial
Hello. > 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. What about simply having compile-time modules? When you compile, if you have Python then the module is compiled, it not then it isn't, end of story :) Regards Nicolas signature.asc Description: This is a digitally signed message part. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Crossfire server code cleanup/janitorial
On 04/23/2014 01:19 AM, Kevin Zheng wrote: I'm still not sure why this would make the project more portable, though. The major compiler toolchains support C just as well as C++, with the notable exception of Visual Studio. It is not only the language and the employed toolchain. In my experience, problems begin as soon as you start implementing containers and data structures in C (which, btw, has been done in crossfire). It is then a good idea to use standardized library functions, like, strings, lists, or hash tables. All this is provided by C++ for free in a highly portable way. I tend to agree, though, I have had some bad experience in another project with a lot of false-positives using VS 2008. Using GCC, I would always recommend compiling with -W -Wall. Right now the code seems to compile fairly cleanly. Try compiling with gcc 4.8. While almost all issues are minor (unused variables and signed compares), there is some work left with at least GCC. I haven't tried other compilers though. While strlcat and strlcpy are not defined by any standards body, I believe that they are superior to the normal functions and should be used whenever possible. If you haven't noticed, I recently committed a small chunk of platform-dependent code that uses these two functions when available instead of our hacks around it. Yes, and that's a good progress! However, I still fail to understand why strlcat/strlcpy would be superior to strncat/strncpy. Right now Crossfire seems maintainable. Recently, several important bug fixes were made, and few new features were introduced. As I said before, these developments have inspired me to start this (quite long) thread. And to repeat: I believe that the overall quality of the source code is really good. Still there is some way to go. Thanks for your work! Even then, some specifics would be useful. What are you suggesting for networking or the server loops? I haven't had thought about it well enough, but I can think of two possibilities: a) refactor/rewrite the code. b) use third-party libraries. My preference is of course b), however, such a step must be thoroughly investigated beforehand. At the end of the day, if you believe that certain changes are worth your time making, please send a patch. The recent cleanups were made because I wanted them and nobody objected to them. While I really appreciate the positive discussion we have had up until now, my impression is that I should now be showing you what I have in mind rather than doing mouth-work only :) On github, I have created a crossfire server repository to track my patches (based on SVN trunk rev. 19362). https://github.com/tdalman/crossfire I won't be able to test any other platform than Linux and I won't be attempting to do so either. If you think some of the changes are worthwhile to adopt, I'd be happy of course. Likewise, please don't hesitate to comment on my patches. I will try to keep the code in sync, but at some point that will no longer be possible. Best regards Tolga Dalman ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Crossfire server code cleanup/janitorial
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.
___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Crossfire server code cleanup/janitorial
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/22/2014 11:19, Juha Jäykkä wrote: >> It would be nice to sit down and come up with a roadmap. I've >> been doing so much 'cleanup' work lately because I didn't have >> anything specific in mind to work on. > > What happened to that rebalancing-related roadmap from a few years > ago? Did it ever get finished? I must admit I have not even logged > on to a Crossfire server for years, which is pretty sad. Probably not, although I wasn't around back then to be able to tell. A lot of things, including experience tables, spell levels, player stats, artifact properties, item prices, weights, and more still need a lot of balancing and tweaking. Unfortunately, the only balancing that I am capable of performing is for object weights. Simply copy real-world values in :D Thanks, Kevin Zheng -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (FreeBSD) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTVvrNAAoJEOrPD3bCLhCQxgMIALz3IR7llW0arn/QUfOdoxsA 5j5UxoUzuUMuY/txtcxhDcibr9CIXDYswEOcL5YqYoLZo2lJ5cGnXVnB8BYZYniC 41NBlvFyKBsOm/S0Frpk0fRSHZ1ajVCJ7f2xsmsZOnjjDrPuqrERbzl9xDTbGbw+ gUWY+gtv9qvVw1hviosXFZ7DF/IOh8V9Su7+6JPAkb0WbS+cMq87T4IWcCfvYt+t 6M8zJwNduVefKc+iA/mRPTahrUkd/6iCmXhsAamq1zFPr+Wl/gQ1GGVnrdQkGvTE hJZTAC6QmK8Y3mN4rb4Elm61RqvNqisjIbuXW33+N8dw7UwRWBZub4lguBbEst4= =ZKV5 -END PGP SIGNATURE- ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Crossfire server code cleanup/janitorial
On 04/22/2014 03:20, Tolga Dalman wrote: >> 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' > > Exactly. My point is that the code MUST be compilable by a set of > specific toolchains by following a specific standard (e.g., C99). > Some C99 features will probably not work on all specified toolchains, > thus, those must be omitted in the code. I see no need for checking > for a specific compiler. Instead, I'd just assume it. The problem is that now we have to explicitly define a list of features that are allowed in the code. Technically, neither GCC nor Clang are C99 compliant because they lack certain floating type macros. This does not concern us because we don't really care about floating point operations. Likewise, I think it's a good idea to change the language standard to C99, but only use features where it makes sense. If we do decide to change language standard, there is no immediate need to jump in and use every single new feature, either. >>> 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++. > > No. I'm thinking of the GCC project -- they are doing it this way. > The incompatibilities are really restricted to struct initialization > and using C++ keywords as variables or functions (like new or > class). BTW: that book is neither a good reference, nor a good C++ > tutorial, IMHO. I'm still not sure why this would make the project more portable, though. The major compiler toolchains support C just as well as C++, with the notable exception of Visual Studio. >> 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. > > I had already compiled the crossfire 1.70 code with C++ using GCC > last year. I can't rembember any serious issues. The choice of compiler should be left to the user. Since this is a project written in C, the 'official' way to compile it should be a C compiler. Note that 'official' only means that someone will get yelled at if a change breaks the compilation. Quite frankly, I still have the (possibly wrong) notion that the most logical choice to compile a C program is a C compiler. >> If anything, for full compatibility, compiling with different >> compilers with full warnings/strict mode may be better. > > I tend to agree, though, I have had some bad experience in another > project with a lot of false-positives using VS 2008. Using GCC, I > would always recommend compiling with -W -Wall. Right now the code seems to compile fairly cleanly. >>> 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 > > TBH I have some problems with strlcat and strlcpy: they are neither > supported by ISO C, nor by POSIX. The glibc project repeatedly > refused to add those functions to the standard library. They offer no > more functionality than strncpy and strncat. Conversely, they are a > known source of potential bugs (a quick Google search for strlcpy and > glibc will reveal the details). While strlcat and strlcpy are not defined by any standards body, I believe that they are superior to the normal functions and should be used whenever possible. If you haven't noticed, I recently committed a small chunk of platform-dependent code that uses these two functions when available instead of our hacks around it. >> 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. > > I guess, we're here in disagreement. If I understood you correctly, > you want to support old compilers, while my approach is to remove old > cruft to make crossfire maintainable. What old toolchains are being >
Re: [crossfire] Crossfire server code cleanup/janitorial
> - Variable length arrays (may be useful in future) Which the C11 standard kindly removed. The stupidest decision by any standards committee ever: to remove perhaps the most important improvement in the previous standard just because some fool compiler manufacturer had not been able to implement it in ten years. > It would be nice to sit down and come up with a roadmap. I've been doing > so much 'cleanup' work lately because I didn't have anything specific in > mind to work on. What happened to that rebalancing-related roadmap from a few years ago? Did it ever get finished? I must admit I have not even logged on to a Crossfire server for years, which is pretty sad. I will go back to my cave now. ;) -- --- | Juha Jäykkä, ju...@iki.fi | | http://koti.kapsi.fi/~juhaj/ | --- signature.asc Description: This is a digitally signed message part. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Crossfire server code cleanup/janitorial
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' Exactly. My point is that the code MUST be compilable by a set of specific toolchains by following a specific standard (e.g., C99). Some C99 features will probably not work on all specified toolchains, thus, those must be omitted in the code. I see no need for checking for a specific compiler. Instead, I'd just assume it. That in many ways works better - oftentimes, compilers will lack full support for certain options, but support the ones we care about. I agree. 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++. No. I'm thinking of the GCC project -- they are doing it this way. The incompatibilities are really restricted to struct initialization and using C++ keywords as variables or functions (like new or class). BTW: that book is neither a good reference, nor a good C++ tutorial, IMHO. 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. I had already compiled the crossfire 1.70 code with C++ using GCC last year. I can't rembember any serious issues. If anything, for full compatibility, compiling with different compilers with full warnings/strict mode may be better. I tend to agree, though, I have had some bad experience in another project with a lot of false-positives using VS 2008. Using GCC, I would always recommend compiling with -W -Wall. 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 TBH I have some problems with strlcat and strlcpy: they are neither supported by ISO C, nor by POSIX. The glibc project repeatedly refused to add those functions to the standard library. They offer no more functionality than strncpy and strncat. Conversely, they are a known source of potential bugs (a quick Google search for strlcpy and glibc will reveal the details). 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. I guess, we're here in disagreement. If I understood you correctly, you want to support old compilers, while my approach is to remove old cruft to make crossfire maintainable. What old toolchains are being used and which of them do you want to support and test ? 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 had
Re: [crossfire] Crossfire server code cleanup/janitorial
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. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Crossfire server code cleanup/janitorial
On 04/21/2014 04:20, Tolga Dalman wrote: > My impression about crossfire right now is that the development in > the server and client code is pretty dormant for the last few years. > At the same time, however, I notice some increased activity towards > cleanup work. I want to take this impetus as a reason to contribute > by myself. More help with Crossfire is always welcome. > Two reasons are holding me currently up to contribute, in fact: 1. > There is no roadmap or "vision". Admittedly, crossfire runs pretty > fine for ages now, nevertheless, I do see some open issues. 2. Parts > of the code is crufty and even messy. To be honest, I'm scared off > fixing issues I find in the code because of this. Having a roadmap or vision is a good idea. Right now mine is to make sure the game works on my operating system and keep it that way. My other vision is to make Crossfire more fun, but without any crystallization that's not very productive. I have many, many open issues with Crossfire, but I haven't considered them important enough to dedicate substantial work to them yet. I'd love to hear your issues so we can start discussing and working on those right now. > 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. > 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++. > 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. > 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. Thanks, Kevin Zheng ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Crossfire server code cleanup/janitorial
On 04/21/2014 01:23, Mark Wedel wrote: > Going back to to the original thread - certainly win32 is used, and I > also do sun/solaris. Solaris support seems like a good idea to keep. > I think some of that might be sound code for the client - though even > on linux, it seems that the sound 'standard' changes every 5 years or so. Sound support is now handled by SDL_Mixer, which works well with OSS, ALSA, PulseAudio, and the myriad of sound systems there are. Most, if not all of the platform-dependent code there has been removed. > Changing C standard is certainly something worth discussing - C99 would > be reasonable (in my mind) - C11 may be a bit too recent - while it may > be widely supported, it might also mean that certain users would be > forced to upgrade their compilers (and perhaps other parts of their > system) faster than they really want. But it also really comes down to > features - What C11 (or even C99) features are out there that would be > of benefit to crossfire? I'm not familiar enough with the different > standards to make any assessment on that. C99 has many new shiny features that I would really like to use. - Intermingled declarations with better locality of reference - Exact-width integer types (we try to hack around this right now) - New boolean data type (hacked around with our TRUE/FALSE macros) - Variable length arrays (may be useful in future) - Inline functions, to replace some macros in use - New style comments (trivial, but useful) - New library functions like 'snprintf' (used for quite some time) Of course, right now the blocking issue is compiler support, specifically from Microsoft. Both GCC and Clang support C99, except for a few floating point operations, and so do a number of popular compilers (Intel, maybe more). > C++ has been touched on some. I'd add that there are going to be more C > programmers than C++ programmers, just on the basis that to know C++, > you need to know C. So by switching to C++, you may very lose some > number of current or future potential developers. Personally, I prefer C simply because I don't know C++ (yet). Aside from greedy selfishness, I don't think a (partial) rewrite in C++ will be useful. C++ has nice features, but our aging code has done fine without so far. > So echoing some previous comments, I think gameplay should drive more > new features. I also think it would be helpful to express what the > benefits of the changes are. Right now there's no pressing feature that requires C++ in order to implement. As far as I can see (which isn't very far) C is fine for the job. Of course, I don't know what job this is, which means... > In terms of roadmap, I think there were some out on the wiki. But like > most volunteer based projects, trying to stick to any such roadmap gets > difficult - people tend to work on what they want to work on, and it may > or may not match something on the roadmap. It would be nice to sit down and come up with a roadmap. I've been doing so much 'cleanup' work lately because I didn't have anything specific in mind to work on. Thanks, Kevin Zheng ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Crossfire server code cleanup/janitorial
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 4/19/14 11:45 AM, Tolga Dalman wrote: > > That's what I thought. Do you have any download statistics for, > say, Windows binaries ? Some stats[1] are available, but they don't show the whole picture as there are other sites[2] that offer file downloads or the download information is not tracked for other (unknown) reasons[3]. The server log files can track number of connections and client versions from players, but at the moment there is no "nice" way to really collect player population data -- like one could gain from using one of the many website traffic analyzers. Meaning, no easy way to tell if a person with Client X has connected 10 times today or if that was 10 different people. [1] = http://sourceforge.net/projects/crossfire/files/crossfire-server-windows/stats/timeline [2] = http://www.meflin.net/crossfire/ [3] = http://sourceforge.net/projects/crossfire/files/crossfire-client/snapshot/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iD8DBQFTVWVEhHyvgBp+vH4RAnHNAJ40cKeFNY7fMba9YbsVhSSUPznqbgCgndfI oLEmw2o3UaY/E53nlk7vyYU= =KzjE -END PGP SIGNATURE- ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Crossfire server code cleanup/janitorial
My impression about crossfire right now is that the development in the server and client code is pretty dormant for the last few years. At the same time, however, I notice some increased activity towards cleanup work. I want to take this impetus as a reason to contribute by myself. Two reasons are holding me currently up to contribute, in fact: 1. There is no roadmap or "vision". Admittedly, crossfire runs pretty fine for ages now, nevertheless, I do see some open issues. 2. Parts of the code is crufty and even messy. To be honest, I'm scared off fixing issues I find in the code because of this. I have no intent to start a flame war about anything or breaking functionality. Instead, I'd like you to consider my proposal consisting of these steps: 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. 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. 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. 4. Modernize architecture and replace existing components. Best regards Tolga Dalman On 04/21/2014 08:23 AM, Mark Wedel wrote: Going back to to the original thread - certainly win32 is used, and I also do sun/solaris. I'm not sure if there is any conditional code based on platforms in crossfire - if there is, I would think most could be removed through proper configure checks (that code may predate the conversion to autoconf). I suspect in the case of sgi/irix, vax/ultrix and perhaps a few others, if support disappeared, no one would care. But without knowing specific areas, support for those might also be part of support for other platforms (something like a #if defined(irix) || defined(sun) ) or the like, so just removing irix doesn't do much. I think some of that might be sound code for the client - though even on linux, it seems that the sound 'standard' changes every 5 years or so. Changing C standard is certainly something worth discussing - C99 would be reasonable (in my mind) - C11 may be a bit too recent - while it may be widely supported, it might also mean that certain users would be forced to upgrade their compilers (and perhaps other parts of their system) faster than they really want. But it also really comes down to features - What C11 (or even C99) features are out there that would be of benefit to crossfire? I'm not familiar enough with the different standards to make any assessment on that. C++ has been touched on some. I'd add that there are going to be more C programmers than C++ programmers, just on the basis that to know C++, you need to know C. So by switching to C++, you may very lose some number of current or future potential developers. I'm also suspect that doing a piecemeal conversion wouldn't be at all useful - while there is lots of crufty code in crossfire, you'd really want to look and figure out how all the classes interact and so forth. Otherwise, you may just end up with a C++ version of crossfire which is fundamentally the same, just written in C++. I'm always a bit concerned about rewriting stuff just for the sake of rewriting - while it may find (and fix) some existing bugs in the code, almost certainly more new bugs will be introduced. So echoing some previous comments, I think gameplay should drive more new features. I also think it would be helpful to express what the benefits of the changes are. In terms of roadmap, I think there were some out on the wiki. But like most volunteer based projects, trying to stick to any such roadmap gets difficult - people tend to work on what they want to work on, and it may or may not match something on the roadmap. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Crossfire server code cleanup/janitorial
Going back to to the original thread - certainly win32 is used, and I also do sun/solaris. I'm not sure if there is any conditional code based on platforms in crossfire - if there is, I would think most could be removed through proper configure checks (that code may predate the conversion to autoconf). I suspect in the case of sgi/irix, vax/ultrix and perhaps a few others, if support disappeared, no one would care. But without knowing specific areas, support for those might also be part of support for other platforms (something like a #if defined(irix) || defined(sun) ) or the like, so just removing irix doesn't do much. I think some of that might be sound code for the client - though even on linux, it seems that the sound 'standard' changes every 5 years or so. Changing C standard is certainly something worth discussing - C99 would be reasonable (in my mind) - C11 may be a bit too recent - while it may be widely supported, it might also mean that certain users would be forced to upgrade their compilers (and perhaps other parts of their system) faster than they really want. But it also really comes down to features - What C11 (or even C99) features are out there that would be of benefit to crossfire? I'm not familiar enough with the different standards to make any assessment on that. C++ has been touched on some. I'd add that there are going to be more C programmers than C++ programmers, just on the basis that to know C++, you need to know C. So by switching to C++, you may very lose some number of current or future potential developers. I'm also suspect that doing a piecemeal conversion wouldn't be at all useful - while there is lots of crufty code in crossfire, you'd really want to look and figure out how all the classes interact and so forth. Otherwise, you may just end up with a C++ version of crossfire which is fundamentally the same, just written in C++. I'm always a bit concerned about rewriting stuff just for the sake of rewriting - while it may find (and fix) some existing bugs in the code, almost certainly more new bugs will be introduced. So echoing some previous comments, I think gameplay should drive more new features. I also think it would be helpful to express what the benefits of the changes are. In terms of roadmap, I think there were some out on the wiki. But like most volunteer based projects, trying to stick to any such roadmap gets difficult - people tend to work on what they want to work on, and it may or may not match something on the roadmap. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Crossfire server code cleanup/janitorial
Hello. > The real question is: what is the future of Crossfire ? I agree to Nicolas > that focussing on game content is more important than code. However, the > current code architecture restricts the maintenance and addition of new > features. I'd like to improve this situation. What are you trying to do that you can't with the current code? :) About the future of Crossfire, it's harder to tell, unfortunately. We definitely lack a "roadmap", something towards we all work, a common vision of what the game should be. Too many things are not balanced, and such. For what is worth, I once had a prototype in C++/Qt, not with full classes yet, but the move wasn't too messy, just took some time. So I wouldn't be opposed to moving to C++ (with Qt for the multiplatform aspect :)), but only if most people are ok and if it really is required for some things. And if that doesn't prevent people from first thinking about the content. Therefore I would first like to define what we want, then think about how to achieve those goals - migrating if required. Regards Nicolas signature.asc Description: This is a digitally signed message part. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Crossfire server code cleanup/janitorial
On 04/19/2014 05:01 PM, Kevin Zheng wrote: On 04/19/2014 03:46, Tolga Dalman wrote: 1. What platforms are still relevant ? Beside Linux and BSD, I found references to these OSes: win32, hurd, hpux, ultrix, osf1, sgi, sun, vax, ibm032. Right now, there are many people using Windows, Linux, BSD, and OSX. Most recent development took place on Linux and BSD. That's what I thought. Do you have any download statistics for, say, Windows binaries ? While it's hard to imagine someone running a Crossfire server on VAX or an IBM032, I don't think it's necessary to go in and explicitly pull out support. I highly doubt those platforms still work _with_ current support, because nobody has been able to test. Crossfire tries to be portable, so a good goal would be to remove conditional compilations from most of the source code. In an ideal world every portable project should run on any semi-compliant system with appropriate libraries installed. My proposal aims at specifying the requirements on platform and programming language for running crossfire. In an ideal world, all supported platforms meeting the requirements are perfectly supported. Everything else needs to be adapted. Right now, I only see the above mentioned OSes as being relevant. So my question: where are the user's of crossfire really ? 2. What C standard is relevant ? Moving towards C99 or even C11 would allow large portions of cleanups (standard functions, types, language constructs, etc). I think moving to C99 is a good idea, but right now the blocking issue seems to be Visual Studio, which is used to build the server on Windows. It'd be interesting to find out how much C99 VS supports. AFAIK, C99 is not an issue with VS12. 3. What about the use of C++ (2011) ? It is clearly possible to smoothly convert existing code to C++ which allows better maintenance of the code. That looks like a long-term goal, because I don't see that happening until more stuff is cleaned up. As Nicholas mentioned, there isn't a pressing need for C++. That, and I don't know C++ :D Talking about portability, C++ is really the best choice, especially when it comes to Windows & VS. Since C99 is almost entirely a subset of the C++ language, an approach would be to compile all code with a C++ compiler. With that done, some nice C++ features can be used out of the box. Afterwards, modules can be replaced by real C++ classes. But that, as you said, is a long-term goal. The real question is: what is the future of Crossfire ? I agree to Nicolas that focussing on game content is more important than code. However, the current code architecture restricts the maintenance and addition of new features. I'd like to improve this situation. Best regards Tolga Dalman ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Crossfire server code cleanup/janitorial
On 04/19/2014 03:46, Tolga Dalman wrote: > 1. What platforms are still relevant ? Beside Linux and BSD, I found > references to these OSes: win32, hurd, hpux, ultrix, osf1, sgi, > sun, vax, ibm032. Right now, there are many people using Windows, Linux, BSD, and OSX. Most recent development took place on Linux and BSD. While it's hard to imagine someone running a Crossfire server on VAX or an IBM032, I don't think it's necessary to go in and explicitly pull out support. I highly doubt those platforms still work _with_ current support, because nobody has been able to test. Crossfire tries to be portable, so a good goal would be to remove conditional compilations from most of the source code. In an ideal world every portable project should run on any semi-compliant system with appropriate libraries installed. > 2. What C standard is relevant ? Moving towards C99 or even C11 would > allow large portions of cleanups (standard functions, types, language > constructs, etc). I think moving to C99 is a good idea, but right now the blocking issue seems to be Visual Studio, which is used to build the server on Windows. It'd be interesting to find out how much C99 VS supports. > 3. What about the use of C++ (2011) ? It is clearly possible to > smoothly convert existing code to C++ which allows better maintenance > of the code. That looks like a long-term goal, because I don't see that happening until more stuff is cleaned up. As Nicholas mentioned, there isn't a pressing need for C++. That, and I don't know C++ :D Thanks, Kevin Zheng ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Crossfire server code cleanup/janitorial
Hello. Thanks for your interest in Crossfire :) Concerning the first point, I'd say Windows is relevant (though having statistics on clients running Windows would be nice), others I don't know. For point 2), not sure, I think the code is globally ANSI C. See next point though :) And for point 3), that's another can of worm entirely :) My personal reply would be "right now I can more about content and gameplay than code, so let's forget refactorings until we really need it (hitting a wall the current code can't handle, for instance). :) Regards Nicolas Le samedi 19 avril 2014 10:46:34, Tolga Dalman a écrit : > Dear community, > > first of all: thank you very much for your efforts in the development of > crossfire. I'm a keen player of this game since around 2002. > > Recently, I noticed several cleanup and janitorial work in the trunk. I > wonder whether there should be done more. Looking through the code, I have > to say that the overall quality of the server sources is really good. > However, crossfire is a software that has evolved since at least 1995. > > Hence, I would like to ask you, the developer community, a number of > general questions about the future of the crossfire (server) development: > > 1. What platforms are still relevant ? Beside Linux and BSD, I found > references to these OSes: win32, hurd, hpux, ultrix, osf1, sgi, sun, vax, > ibm032. > > 2. What C standard is relevant ? Moving towards C99 or even C11 would allow > large portions of cleanups (standard functions, types, language constructs, > etc). > > 3. What about the use of C++ (2011) ? It is clearly possible to smoothly > convert existing code to C++ which allows better maintenance of the code. > > Please understand these questions as a constructive effort to further > improve the quality of the current code basis. > > Best regards > Tolga Dalman > > > ___ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire signature.asc Description: This is a digitally signed message part. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
[crossfire] Crossfire server code cleanup/janitorial
Dear community, first of all: thank you very much for your efforts in the development of crossfire. I'm a keen player of this game since around 2002. Recently, I noticed several cleanup and janitorial work in the trunk. I wonder whether there should be done more. Looking through the code, I have to say that the overall quality of the server sources is really good. However, crossfire is a software that has evolved since at least 1995. Hence, I would like to ask you, the developer community, a number of general questions about the future of the crossfire (server) development: 1. What platforms are still relevant ? Beside Linux and BSD, I found references to these OSes: win32, hurd, hpux, ultrix, osf1, sgi, sun, vax, ibm032. 2. What C standard is relevant ? Moving towards C99 or even C11 would allow large portions of cleanups (standard functions, types, language constructs, etc). 3. What about the use of C++ (2011) ? It is clearly possible to smoothly convert existing code to C++ which allows better maintenance of the code. Please understand these questions as a constructive effort to further improve the quality of the current code basis. Best regards Tolga Dalman ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
