Samba 2.2.2 problem in lib/sprintf.c
John E. Malmberg
wb8tyw at qsl.net
Mon Nov 26 21:56:02 GMT 2001
On Mon, Nov 26, 2001 at 09:00:38PM -0800, Andrew Tridgell wrote:
>
>no, the original code was correct. The patch breaks Samba on LOTS of
>platforms.
The original code has proven to be broken on several platforms, and
will not build. Either the compiler optimizer dies, or the resulting
object modules will not link.
>The logic is that we want to do our own *snprintf() code if either the
>system doesn't have it OR the systems one is broken.
It appears that the configure algorithm may have trouble getting the
appropriate #defines right. From looking at the various configure
scripts and source modules, it is not clear to me how to determine which
#defines to set (or not set) to resolve the problem.
Many systems will not allow a global procedure name conflict with one
that is supplied in a standard library. It produces a duplicate symbol
conflict at link time.
It is compounded in the case of the "printf" family of functions, as a
good optimizing compiler will not actually generate a printf (or
friends) call if it can avoid it. It will instead calculate either
inline code or the individual routines needed to format the string.
Basically skipping the run time parse of the format string for an
increase in speed.
This same type of optimizations are also usually done for most of the
string functions, so setting up safe_strcpy() as a global function
instead of a macro will have an adverse affect on performance. Enough
to make a difference? I do not know. It would take some benchmarks and
possibly a code profiler to tell for sure.
If samba wants to supply it's own replacement routines for standard
library calls, I recommend changing the name of the routines to have
unique symbols like smb_snprintf() so that there is never a conflict
with existing symbols in a standard library.
If configure determines that the existing snprintf() function is good
enough, then it can #define smb_snprintf() printf(). And all platforms
will be happy.
-John
wb8tyw at qsl.network
Personal Opinion Only
More information about the samba-technical
mailing list