mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Rich Felker <dalias@libc.org>
To: musl@lists.openwall.com
Subject: Re: [PATCH 2/4] cimag and friends shouldn't return an lvalue
Date: Tue, 2 Dec 2014 12:58:26 -0500	[thread overview]
Message-ID: <20141202175826.GC29621@brightrain.aerifal.cx> (raw)
In-Reply-To: <1416926859.16006.924.camel@eris.loria.fr>

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


  reply	other threads:[~2014-12-02 17:58 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-11-25 14:49 Jens Gustedt
2014-12-02 17:58 ` Rich Felker [this message]
2014-12-02 19:13   ` Jens Gustedt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20141202175826.GC29621@brightrain.aerifal.cx \
    --to=dalias@libc.org \
    --cc=musl@lists.openwall.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).