The sql_string.h String class has some strange code to null-terminate the string for String::c_ptr(). It checks if the string is already null-terminated, and only writes the '\0' at the end if it is not already there. The reason for this I think is to avoid the re-allocation of the buffer to fit the null termination at append time if it is not needed due to never calling c_ptr(). However, the problem case here is a different one, where the null termination fits in the given buffer, but the value is uninitialised. In this case, checking before zeroing works (if in a somewhat twisted way). But it causes a false Valgrind alarm. This is a minimal fix; not sure if it is the right one. Maybe it would be better to fix the c_str() method to not use this tricky way of working? --- sql/sql_string.h | 8 ++++++++ 1 file changed, 8 insertions(+) Index: work-5.1-buildbot/sql/sql_string.h =================================================================== --- work-5.1-buildbot.orig/sql/sql_string.h 2009-04-08 00:34:49.000000000 +0200 +++ work-5.1-buildbot/sql/sql_string.h 2009-04-08 00:35:38.000000000 +0200 @@ -99,7 +99,15 @@ public: inline const char *ptr() const { return Ptr; } inline char *c_ptr() { + /* + This code null-terminates the string if not already null-terminated. + This works whether Ptr[str_length] is undefined or not, but if undefined + it generates a Valgrind error. So in the Valgrind case, null-terminate + unconditionally. + */ +#ifndef HAVE_purify if (!Ptr || Ptr[str_length]) /* Should be safe */ +#endif (void) realloc(str_length); return Ptr; } --