[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 2 Dec 2014 12:58:26 -0500
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: [PATCH 2/4] cimag and friends shouldn't return an lvalue
On Tue, Nov 25, 2014 at 03:49:55PM +0100, Jens Gustedt wrote:
> 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))
> +#else
> #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])
> +#endif
Short of a good reason to need the GNU-specific version (like subtle
non-conformance, performance issues, or other problems in the portable
version), it's generally preferred in musl not to have multiple
versions of the same code where one would go largely untested. But
making it a non-lvalue seems like a good idea just to catch bugs.
Rich
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.
