stdatomic.h not C11 compliant with Objective C framework

[llvmbot]

Bugzilla Link	40769
Version	trunk
OS	MacOS X
Reporter	LLVM Bugzilla Contributor
CC	@asl,@topperc,@zygoloid

Extended Description

On Mac OSX 10.4 (Mojave) with Apple LLVM Version 10.0.0 (clang-1000.11.45.5)

I have written my own <stdatomic.h> for multiple platforms that don't support it. It is designed to work under all C11-compliant compilers. My own <stdatomic.h> has a gate that says:

#ifndef STDC_NO_ATOMICS

error ... error text goes here ...

#endif

As my entire source repository is a shared repository, this file is visible during compilation on all platforms. I use "-idirafter" to make sure that any file provided by the hosted environment gets picked up before my file.

If clang on Mac OSX is invoked on a file with ".c" extension then the hosted environment doesn't supply <stdatomic.h>. In this case STDC_NO_ATOMICS is defined, my custom file is called, and it compiles cleanly.

However, for the Objective C framework, LLVM headers provide a <stdatomic.h>. Inside this file is the following:

#if STDC_HOSTED && __has_include_next(<stdatomic.h>)

include_next <statomic.h>

#endif

The extension "include_next" searches "-idirafter" and sees my <stdatomic.h> and includes it, but it does not define STDC_NO_ATOMICS so the gate within my custom <stdatomic.h> is entered and the build always fails. This appears to be a violation of C2011.

[zygoloid]

This appears to be a violation of C2011.

I don't think so; see C11 7.1.2/3: "If a file with the same name as one of the above < and > delimited sequences, not provided as part of the implementation, is placed in any of the standard places that are searched for included source files, the behavior is undefined."

The idea of our <stdatomic.h> header is to get out of the way and let the system <stdatomic.h> do its thing if the libc provides it. This is necessary for correct behavior on some BSDs. It doesn't make sense for us to define STDC_NO_ATOMICS in that case, since we're just deferring to another <stdatomic.h> which we assume to provide a proper implementation of that header, and shouldn't be assuming that it will fail to do so (which is what defining STDC_NO_ATOMICS would mean), or that it will #undef that macro (the BSD one won't).

The most compatible / compliant thing to do would be to make your <stdatomic.h> header not be in the include search path for a compiler that provides a working <stdatomic.h>. Otherwise, a Clang-specific workaround such as #ifdef clang or #if __has_feature(c_atomic) would be another possible approach, but you'd still need to provide your own <stdatomic.h> implementation in that case.

[llvmbot]

I did consider the suggestions put forward but unfortunately I am not particularly keen on any of them.

I see little merit in bending standard-compliant source code to fit a particular Translation Environment when the whole goal of being "standard compliant" is to be independent of any one Translation Environment. Furthermore, any single Translation Environment that forces source code to recognise its existence in order to be "standard compliant" cannot, by extension, call itself "standard compliant".

STDC_NO_ATOMICS is "intended to indicate that the implementation does not support atomic types (including the _Atomic type qualifier) and the <stdatomic.h> header" (C11, 6.10.8.3). So, how is it that a Hosted Implementation (i.e., one that sets STDC_HOSTED) can both not provide the header and not set STDC_NO_ATOMICS and yet still be considered compliant? In this instance, <stdatomic.h> may be physically present in a "standard place", but the net effect of translation is as if it were missing. The most compliant way a program can detect whether the Translation Environment supports <stdatomic.h> is to test the value of the STDC_NO_ATOMICS macro, except that in this particular Translation Environment it does not appear to be functioning the way the Standard intended.

Another point, which possibly has more to do with common sense rather than the interpretation of "undefined behaviour" (C11 7.1.2/3), is to consider why "-idirafter" was introduced and for what purpose it was intended. "-idirafter" appends to the list of "standard places". However, why was this considered necessary over the standard "-I" which prepends a directory to the list of "standard places"? The current implementation of clang's <stdatomic.h> means that if a directory forming part of the program code, not the Translation Environment, has a file called <stdatomic.h>, then this file gets included whether the path it is in is specified using "-I" or "-idirafter"; i.e., there is the illusion that it is missing from the Translation Environment while, conversely, the lack of STDC_NO_ATOMICS implies that it is present. In this case, the implementation of a Translation Environment seeking to be compliant appears to be contradicting itself.