Re: [crossfire] Crossfire server code cleanup/janitorial

2014-04-25 Thread Kevin Zheng
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

Re: [crossfire] Crossfire server code cleanup/janitorial

2014-04-24 Thread Tolga Dalman
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

Re: [crossfire] Crossfire server code cleanup/janitorial

2014-04-23 Thread Mark Wedel
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

Re: [crossfire] Crossfire server code cleanup/janitorial

2014-04-23 Thread Tolga Dalman
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

Re: [crossfire] Crossfire server code cleanup/janitorial

2014-04-23 Thread Nicolas Weeger
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

Re: [crossfire] Crossfire server code cleanup/janitorial

2014-04-22 Thread Tolga Dalman
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

Re: [crossfire] Crossfire server code cleanup/janitorial

2014-04-22 Thread Juha Jäykkä
- 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

Re: [crossfire] Crossfire server code cleanup/janitorial

2014-04-22 Thread Kevin Zheng
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

Re: [crossfire] Crossfire server code cleanup/janitorial

2014-04-22 Thread Kevin Zheng
-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

Re: [crossfire] Crossfire server code cleanup/janitorial

2014-04-21 Thread Mark Wedel
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

Re: [crossfire] Crossfire server code cleanup/janitorial

2014-04-21 Thread Kevin Zheng
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

Re: [crossfire] Crossfire server code cleanup/janitorial

2014-04-21 Thread Kevin Zheng
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

Re: [crossfire] Crossfire server code cleanup/janitorial

2014-04-20 Thread Nicolas Weeger
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

Re: [crossfire] Crossfire server code cleanup/janitorial

2014-04-19 Thread Kevin Zheng
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

Re: [crossfire] Crossfire server code cleanup/janitorial

2014-04-19 Thread Tolga Dalman
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,