Blame zarafa-7.0.8-va_list.patch

e14f982
Patch by Robert Scheck <robert@fedoraproject.org> for zarafa >= 7.0.8, which works
e14f982
around the insane written C/C++ code. I am not a C/C++ developer, but you only can
e14f982
use four macros for handling va_list at all: va_start, va_arg, va_copy and va_end.
e14f982
e14f982
As a developer you should not assume that va_list is always internally typed as an
e14f982
integer because it is case on i?86 and x86_64 for example. Architectures like ARM
e14f982
handle va_list not as an integer and thus fail during compiling like this:
e14f982
e14f982
Trace.cpp:129:16: error: invalid operands of types 'va_list {aka __va_list}' and
e14f982
  'int' to binary 'operator!='
e14f982
Trace.cpp:142:16: error: invalid operands of types 'va_list {aka __va_list}' and
e14f982
  'int' to binary 'operator!='
e14f982
e14f982
As it is unfortunately not safe to assume that format does not contain attributes
e14f982
while va is empty this workaround is only applied on the affected ARM architecture
e14f982
for now. The only real solution is a clean rewrite of the code that should happen
e14f982
upstream.
e14f982
e14f982
--- zarafa-7.0.8/common/Trace.cpp		2012-06-18 18:55:29.000000000 +0200
e14f982
+++ zarafa-7.0.8/common/Trace.cpp.va_list	2012-06-20 01:20:06.000000000 +0200
e14f982
@@ -126,7 +126,11 @@
e14f982
 
e14f982
 	len = pos + 3;
e14f982
 
e14f982
+#if defined __ARM_EABI__
e14f982
+	if (format) {
e14f982
+#else
e14f982
 	if (format && va) {
e14f982
+#endif
e14f982
 		va_copy(va_lentest, va);
e14f982
 		len += _vsnprintf(NULL, 0, format, va_lentest);
e14f982
 		va_end(va_lentest);
e14f982
@@ -139,7 +143,11 @@
e14f982
 
e14f982
 	memcpy(buffer, debug, pos);
e14f982
 
e14f982
+#if defined __ARM_EABI__
e14f982
+	if (format)
e14f982
+#else
e14f982
 	if (format && va)
e14f982
+#endif
e14f982
 		pos = _vsnprintf(buffer+pos, len-pos, format, va);
e14f982
 
e14f982
 	if(pos == -1) {