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
the
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 librari
> 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 oper
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/d
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
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
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 librar
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
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
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
-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-r
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 i
> - 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 impleme
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 w
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 st
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
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 'stan
-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 down
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 ar
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
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 tr
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
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
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 poi
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
25 matches
Mail list logo
