Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Tue, 25 Nov 2014 15:49:55 +0100
From: Jens Gustedt <>
Subject: [PATCH 2/4] cimag and friends shouldn't return an lvalue

This is nothing imperative, but is a bit more user friendly, because it
should error out in situations that a user of these macros can't expect
to work.

If __GNU__ is detected, this uses the "__imag__" extension of gcc and
friends. This should be the less costly solution. It should not create a
temporary object, even in absence of optimization. This extension is
arround in all versions of gcc that provide complex arithmetic.
 include/complex.h | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/include/complex.h b/include/complex.h
index 3e14e04..be5bd7e 100644
--- a/include/complex.h
+++ b/include/complex.h
@@ -101,8 +101,13 @@ double creal(double complex);
 float crealf(float complex);
 long double creall(long double complex);
+#ifdef __GNUC__
+#define __CIMAG(x, t) \
+	(__extension__ __imag__ (_Complex t)(x))
 #define __CIMAG(x, t) \
-	((union { _Complex t __z; t __xy[2]; }){(_Complex t)(x)}.__xy[1])
+	(+(union { _Complex t __z; t __xy[2]; }){(_Complex t)(x)}.__xy[1])
 #define creal(x) ((double)(x))
 #define crealf(x) ((float)(x))

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.