musl - Re: [PATCH 1/4] the CMPLX macros must be usable in initializations of static variables

Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <1416987953.28402.26.camel@eris.loria.fr>
Date: Wed, 26 Nov 2014 08:45:53 +0100
From: Jens Gustedt <jens.gustedt@...ia.fr>
To: musl@...ts.openwall.com
Subject: Re: [PATCH 1/4] the CMPLX macros must be usable in
 initializations of static variables

Hello,

Am Mittwoch, den 26.11.2014, 00:19 +0100 schrieb Szabolcs Nagy:
> * Jens Gustedt <jens.gustedt@...ia.fr> [2014-11-25 22:23:03 +0100]:
> > right for all such compilers is quite a pain. I'll see what clang
> > offers, here.
> > 
> 
> clang has
> 
>  static double _Complex z = (double _Complex){x, y};

yes, I noticed that in the mean time, too

> which is problematic because it is a language extension that
> gcc and other c11 compilers wont support most likely

we'd have to do case analysis according to the compiler, anyhow, since
there will be some time that other compilers implement
__builtin_complex, or which would even be better, _Imaginary.

> (a compound literal (T){x,y} is a constraint violation for
> scalar T, so a sensible c11 compiler will emit diagnostics)
> 
> > > and fall back
> > > to the compound literal version otherwise (it wont work as static
> > > initializer then, but right now the biggest user of CMPLX is most
> > > likely musl src/complex/* which dont need it to be constant expr
> > > but does rely on proper semantics for infinites and signed zeros)
> > 
> > If that is so, I'd be in favor of having and using an internal macro
> > that uses the compound literal. The compilation of the library
> > shouldn't depend too much on compiler versions.
> > 
> 
> it used to be an internal macro, but i thought it makes sense
> to use the new CMPLX instead when it was added to complex.h
> 
> but if CMPLX semantics cannot be guaranteed with c99 features

I suppose that these were added to the standard, because such a
feature needs compiler extensions

> then probably we should go back to the internal macro (and not
> define CMPLX at all in complex.h if the semantics is wrong)

I would much be in favor of that, we shouldn't put the quality of the
library implementation in danger just because of some border cases for
this macro. So I prepare a patch in that sense?

Below you see what I have currently, but I don't like it at all.

Jens


#define __CMPLX_NC(x, y, t) (+(union { _Complex t __z; t __xy[2]; }){.__xy = {(x),(y)}}.__z)

#if defined(_Imaginary_I)
# define __CMPLX_I(x, y, t) ((t)(x) + _Imaginary_I*(t)(y))
#else
# define __CMPLX_I(x, y, t) ((t)(x) + _Complex_I*(t)(y))
#endif

#if defined(__clang__)
  /* Clang allows initializer lists for complex numbers and compound
     literals for the initialization of static variables. */
# define __CMPLX(x, y, t) (+(_Complex t){ (x), (y) })
#elif defined(__GNUC__)
# if (__STDC_VERSION__ >= 201112L)
#  define __CMPLX(x, y, t) __builtin_complex((t)(x), (t)(y))
# elif (__GNUC__ >= 3)
#  define __CMPLX(x, y, t) \
  (__builtin_constant_p(x+y) ? __CMPLX_I(x, y, t) : __CMPLX_NC(x, y, t))
# endif
#endif

#ifndef __CMPLX
# define __CMPLX(x, y, t) __CMPLX_I(x, y, t)
#endif

#define CMPLX(x, y) __CMPLX(x, y, double)
#define CMPLXF(x, y) __CMPLX(x, y, float)
#define CMPLXL(x, y) __CMPLX(x, y, long double)



-- 
:: INRIA Nancy Grand Est ::: AlGorille ::: ICube/ICPS :::
:: ::::::::::::::: office Strasbourg : +33 368854536   ::
:: :::::::::::::::::::::: gsm France : +33 651400183   ::
:: ::::::::::::::: gsm international : +49 15737185122 ::
:: http://icube-icps.unistra.fr/index.php/Jens_Gustedt ::



Download attachment "signature.asc" of type "application/pgp-signature" (199 bytes)
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.