maria-developers team mailing list archive

[knielsen@xxxxxxxxxxxxxxx]

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;
   }

--