Imaginary types are not supported, violating ISO C Annex G

[Keith-S-Thompson]

This program:

#include <stdio.h>
#include <complex.h>
int main(void) {
#ifdef __STDC_IEC_559_COMPLEX__
    printf("__STDC_IEC_559_COMPLEX__ is defined as %d\n", __STDC_IEC_559_COMPLEX__);
#else
    printf("__STDC_IEC_559_COMPLEX__ is NOT defined\n");
#endif

#ifdef _Imaginary_I
    printf("Imaginary types are supported\n");
#else
    printf("Imaginary types are NOT supported\n");
#endif
}

compiled with clang -Wall -Wextra -std=c11 -pedantic-errors (llvm version 15.0.0) produces this output:

__STDC_IEC_559_COMPLEX__ is defined as 1
Imaginary types are NOT supported

ISO C Annex G was informative in C99, but was made normative in C11.
Imaginary types are optional in C11, but are mandatory for any
implementation that predefines __STDC_IEC_559_COMPLEX__.
(Complex types were made optional in C11, but that's not relevant here.)

To conform to C11 (and later), clang should either implement imaginary types
as defined in Annex G or remove the definition of __STDC_IEC_559_COMPLEX__.

[llvmbot]

@llvm/issue-subscribers-clang-driver

[llvmbot]

@llvm/issue-subscribers-c11

[shafik]

CC @AaronBallman

[Keith-S-Thompson]

gcc equivalent:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108531

[AaronBallman]

Ugh, this is one of those horrible feature test macros we struggle with.

Clang doesn't currently support imaginary types, but Clang also doesn't define __STDC_IEC_559_COMPLEX__ either, see: https://godbolt.org/z/rsYszj6cb. The problem comes from the <complex.h> header being included, but that header is not under Clang's control: https://godbolt.org/z/1sjr75jh8

Instead, this value comes from stdc-predef.h in glibc: https://sourceware.org/git/?p=glibc.git;a=blob;f=include/stdc-predef.h;h=d3cba52c6fef5e97f7e3a06193cf0206eaff113f;hb=HEAD and if __GCC_IEC_559_COMPLEX is not defined, then it claims you still have standard complex support. This is not the first time glibc's decision to do this sort of thing has caused problems for Clang users: #31001

I marked this as "enhancement" because I ultimately think we want to support imaginary types (which would resolve this issue). However, there's also a case to be made that this is a bug in either glibc (the decision that arbitrary compilers must support optional language features is an odd one to me) or in Clang (perhaps the glibc assumption is that should be defining __GCC_IEC_559_COMPLEX to 0 despite not being GCC).

[Keith-S-Thompson]

FYI, I've sent an email to the C standard editors (the addresses at
the top of the N3054 draft) suggesting that imaginary number support
should be optional even if __STDC_IEC_559_COMPLEX__ and
__STDC_IEC_60559_COMPLEX__ are defined.

It's probably too late to make such a change in C23.

(__STDC_IEC_60559_COMPLEX__ is replacing __STDC_IEC_559_COMPLEX__,
which is obsolescent.)

[Keith-S-Thompson]

Since the definition comes from glibc's stdc-predef.h header, __STDC_IEC_60559_COMPLEX__ is defined if and only if any C standard header is included. (I'm assuming that all C standard headers implicitly include std-predef.h; I haven't verified that).

That's pretty clearly a bug in glibc.

For example, this program:

int main(void) {
#ifdef __STDC_IEC_60559_COMPLEX__
    return 0;
#else
    return 1;
#endif
}

returns with a status of 1, indicating that __STDC_IEC_60559_COMPLEX__ is not defined. If I add #include <stdio.h>, it returns a status of 0.

(And this would not affect implementations that use clang with a library implementation other than glibc.)

[thesamesam]

Since the definition comes from glibc's stdc-predef.h header, __STDC_IEC_60559_COMPLEX__ is defined if and only if any C standard header is included. (I'm assuming that all C standard headers implicitly include std-predef.h; I haven't verified that).

They do not. musl doesn't, for example. See https://reviews.llvm.org/D137043 and https://bugs.gentoo.org/870001.

[Keith-S-Thompson]

My assumption was meant to apply only to glibc-based implementations. I probably didn't make that clear enough.

The idea that non-glibc-based implementations should have all C sources files implicitly include a glibc-provided header seems ... odd. (There's some discussion in the bug reports linked from the previous comment. I haven't read them in enough depth to offer an opinion.)