Samba 2.2.2 problem in lib/sprintf.c

John E. Malmberg wb8tyw at
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

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.

wb8tyw at
Personal Opinion Only

More information about the samba-technical mailing list