> 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
