Backport fix from bug #885538 to fix a build failure with clang 3.4 -

using an empty string instead of a null pointer only does a warning
with clang 3.3.

From brad
This commit is contained in:
landry 2014-01-11 08:35:15 +00:00
parent 2a3fce8509
commit 190bd8ff78
2 changed files with 19 additions and 2 deletions

View File

@ -1,4 +1,4 @@
# $OpenBSD: Makefile,v 1.184 2013/12/26 20:00:33 landry Exp $
# $OpenBSD: Makefile,v 1.185 2014/01/11 08:35:15 landry Exp $
COMMENT-main = Mozilla e-mail, rss and usenet client
COMMENT-lightning = Mozilla Thunderbird calendar extension
@ -18,7 +18,7 @@ ENIG_V = 1.5.2
PKGNAME-enigmail = enigmail-${ENIG_V}
EPOCH-lightning = 0
EPOCH-enigmail = 0
REVISION-main = 0
REVISION-main = 1
REVISION-lightning = 4
REVISION-enigmail = 4

View File

@ -0,0 +1,17 @@
$OpenBSD: patch-mailnews_base_search_src_nsMsgSearchTerm_cpp,v 1.1 2014/01/11 08:35:15 landry Exp $
Fix clang compile failure in nsMsgSearchTerm.cpp by using an empty string
instead of a null pointer, from bug #885538
https://hg.mozilla.org/comm-central/rev/89bbcd5a2293
--- mailnews/base/search/src/nsMsgSearchTerm.cpp.orig Tue Jan 7 23:29:40 2014
+++ mailnews/base/search/src/nsMsgSearchTerm.cpp Tue Jan 7 23:30:53 2014
@@ -197,7 +197,7 @@ nsresult NS_MsgGetStringForAttribute(int16_t attrib, c
}
}
if (!found)
- *string = '\0'; // don't leave the string uninitialized
+ *string = ""; // don't leave the string uninitialized
// we no longer return invalid attribute. If we cannot find the string in the table,
// then it is an arbitrary header. Return success regardless if found or not