[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20141125231925.GB2541@port70.net>
Date: Wed, 26 Nov 2014 00:19:26 +0100
From: Szabolcs Nagy <nsz@...t70.net>
To: musl@...ts.openwall.com
Subject: Re: [PATCH 1/4] the CMPLX macros must be usable in
initializations of static variables
* 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};
which is problematic because it is a language extension that
gcc and other c11 compilers wont support most likely
(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
then probably we should go back to the internal macro (and not
define CMPLX at all in complex.h if the semantics is wrong)
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.
