Am 07.01.2011 14:27, schrieb Samuli Seppänen: > Discussed the snprintf issue in service-win32/openvpnserv.c: > > <http://thread.gmane.org/gmane.network.openvpn.devel/4325> > > Apparently the least bad solution is to replace the mysnprintf function > in openvpnserv.c with a copy of openvpn_snprintf function in buffer.c. > Although this results in some duplicate code, it avoids creating a > dependency from openvpnserv code to openvpn code: currently these > codebases are completely separate. Also, including only one function > ("openvpn_snprintf") from buffer.c object file is probably not possible.
Hi, if you can include only one function from buffer.o depends on platform, compilation environment, and thereabouts - and it requires that the programmer puts up with changed semantics. If that's all given, and if the build platform supports gcc's -ffunction-sections, it's possible, and I've been doing it on a MSP430-based embedded system for a different project for three years or so (and with gcc4 you can use -fdata-sections) -- these options allow the linker to take out individual functions or data items out of an object file, without linking the whole .o file -- but note that it can have minor ill side effects if you play with dynamic linking, weak symbols, and possibly in other situations, for instance, ID strings might go missing. No idea if VC++ can do something similar, or Intel C++, or clang, or tcc, or Codewarrior, or whatever else people use to compile The alternative is to split out openvpn_snprintf plus its dependencies from buffer.c to a separate source file. That would work everywhere and slice down the ballast you're pulling in. As a last resort, the openvpn_snprintf can become a separate file that gets #include "..."-d by buffer.c and by service-win32/openvpnserv.c, then at least you don't have the headaches to remember to change two places when fixing a bug. HTH & best regards -- Matthias Andree
