Files
mu4e/lib
attila a0640a0532 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.
2015-07-02 15:14:29 -05:00
..
2013-07-21 14:44:44 +03:00
2013-03-30 11:32:07 +02:00
2013-03-30 11:32:07 +02:00
2013-03-30 11:32:07 +02:00
2013-03-30 11:32:07 +02:00
2013-03-30 11:32:07 +02:00
2013-06-24 22:44:36 +03:00
2015-02-20 14:50:11 +01:00
2013-03-30 11:32:07 +02:00
2013-03-30 11:32:07 +02:00
2013-03-30 11:32:07 +02:00
2015-03-06 00:12:34 +02:00
2015-02-16 01:19:32 +02:00
2013-03-30 11:32:07 +02:00
2013-03-30 11:32:07 +02:00
2015-02-16 01:19:32 +02:00
2014-10-19 03:27:58 +03:00
2013-07-21 14:44:44 +03:00
2015-03-06 00:12:34 +02:00
2013-03-30 11:32:07 +02:00
2013-05-13 22:30:27 +03:00
2013-03-30 11:32:07 +02:00
2013-03-30 11:32:07 +02:00
2013-03-30 11:32:07 +02:00
2013-03-30 11:32:07 +02:00
2013-03-30 11:32:07 +02:00