Samba 2.2.2 problem in lib/sprintf.c

Andrew Tridgell tridge at
Mon Nov 26 23:02:09 GMT 2001

> 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 optimiser dies?!? That's a little hard to believe. Is the compiler
on your system that broken? Link failures are also surprising.

> It appears that the configure algorithm may have trouble getting the 
> appropriate #defines right.

no, it's that many systems have broken snprintf() implementations. The
C99 standard specifies some very specific behaviour that Samba now
relies on (for very good reasons). Some systems don't follow that
standard. We replace snprintf on those systems.

> 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.

!?! then your linker is badly broken. Can you try the following simple

#include <sys/types.h>

int snprintf(char *str, size_t size, const  char  *format, ...)
	return 0;

	return snprintf("foo", 0, 0);

and see if it compiles. It should on any system. It won't give the
same answer on all systems, but it should *always* compile.

> 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.

we only do this when we absolutely have to. It is better to replace
the broken function where possible.

show me the compiler output from the above test program. Then maybe we
can work out how to fix it. If we need to use a macro we will, but I
would like to know why. I find it hard to believe that the above
simple program won't compile on any system that is even vaguely POSIX.

Cheers, Tridge

More information about the samba-technical mailing list