[Developers] [CactusMaint] Cactus/2058: Util_snprintf() fails for format string "distance=%d threshold=%g %s"

Jonathan Thornburg jthorn at aei.mpg.de
Wed Sep 20 13:37:50 CDT 2006

In bug #2058, I wrote
> Util_snprintf() writes incorrect (garbled) characters
> to the string buffer for the test format string
> "distance=%d threshold=%g %s" (with corresponding
> int, double, and string arguments).
> In particular, given the following C code:
> const int distance = 3;
> const double threshold = 0.0;
> const char* const order_string = "order=2";
> #define N_BUFFER 500
> static char buffer1[N_BUFFER], buffer2[N_BUFFER];
> N1 = snprintf(buffer1, N_BUFFER,
>               "distance=%d threshold=%g %s",
>               distance, threshold, order_string);
> N2 = Util_snprintf(buffer2, N_BUFFER,
>                    "distance=%d threshold=%g %s",
>                    distance, threshold, order_string);
> the correct output (produced by the system snprintf()
> on both test systems) is
> *** standard-library snprintf ***
> N1=30 "distance=3 threshold=0 order=2"
> but on the AEI xeon Util_snprintf() outputs
> *** Cactus Util_snprintf ***
> N2=49 :distance=3 threshold=0.000000e-:
> while on my laptop the output is different (also wrong):
> *** Cactus Util_snprintf ***
> N2=49 "distance=3 threshold=0.000000e-F"

Given that we have had trouble before with our Util_snprintf()
implementation (on 14.Dec.2004 Thomas Radke wrote
# Andre (Wertmann) just found out that one gets wrong string string 
# conversions with the String* functions defined in HTTPD. This holds for 
# 'double' numbers with zeros following right after the decimal point: it 
# just eats all those digits until the first non-zero number (ie. 100.001 
# becomes "100.1").
# I could follow the problem back into Util_snprintf() which seems broken. 
# If one uses sprintf() instead, everything works fine.
), I'd like to propose that instead of patching this bug, we replace
our implementation with  one of the existing free snprintf() versions
on the net.  This function is important, and evidently it's hard to get
right -- we've now had two serious bugs found in our code, and who
knows what other bugs may lurk.....

glibc is GPL and thus against the Cactus-project religion, but all
the *BSD operating systems all include BSD-licensed libc implementations.
For example, OpenBSD's stdio code can be found at
Their vsnprintf() sets up a fake filebuf and uses vsprintf(),
so it would take minor editing to actually use their code.

Apache might be another place to look, or maybe someone has a different
BSD source tree handy and could check there for a clean snprintf().

Any takers?


-- Jonathan Thornburg <jthorn at aei.mpg.de>      
   Max-Planck-Institut fuer Gravitationsphysik (Albert-Einstein-Institut),
   Golm, Germany, "Old Europe"     http://www.aei.mpg.de/~jthorn/home.html      
   "Washing one's hands of the conflict between the powerful and the
    powerless means to side with the powerful, not to be neutral."
                                      -- quote by Freire / poster by Oxfam

More information about the Developers mailing list