From a0640a053283eccb3da7729f0f392af96bcd70de Mon Sep 17 00:00:00 2001 From: attila Date: Thu, 2 Jul 2015 15:14:29 -0500 Subject: [PATCH] Fix call to c_str() that sometimes dumps core on OpenBSD i386-current The core dump only seems to occur if mu4e-headers-include-related is set to t. Apparently, std::string's c_str() method is confusing to many people, c.f. http://stackoverflow.com/questions/22330250/how-to-return-a-stdstring-c-str The answer seems to be that the pointer c_str() returns may not be valid past the current statement; returning it, or even using it subsequently can have you sending a wild pointer into e.g. g_strdup(). In short, it seems idioms like this are okay: return g_strcmp0 (s1.c_str(), s2.c_str()) < 0; Whereas idioms like this are not: const char *msgid (iter->msgid().c_str()); return msgid ? g_strdup (msgid) : NULL; At least in my environment by the time we get to g_strdup() the pointer returned by c_str() is wild and points at garbage. Since g_strdup() returns NULL if passed NULL, it seems collapsing it into a single line is not only possible but necessary. I've looked at all of the calls to c_str() in mu and it appears to me this was the one remaining one that was bad. --- lib/mu-msg-iter.cc | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/lib/mu-msg-iter.cc b/lib/mu-msg-iter.cc index b7099d13..2a1f1966 100644 --- a/lib/mu-msg-iter.cc +++ b/lib/mu-msg-iter.cc @@ -366,9 +366,7 @@ mu_msg_iter_get_msgid (MuMsgIter *iter) g_return_val_if_fail (!mu_msg_iter_is_done(iter), NULL); try { - const char *msgid (iter->msgid().c_str()); - - return msgid ? g_strdup (msgid) : NULL; + return g_strdup (iter->msgid().c_str()); } MU_XAPIAN_CATCH_BLOCK_RETURN (NULL); }