The __has_feature macro is for standard language extensions (prefixed with c_, cxx_, or objc_), while the __has_extension macro is for non-standard language extensions. If -pedantic-errors is set, the __has_extension macro collapses into the same feature set as __has_feature (i.e., it disables non-standard extensions). In either case, the __has_feature macro is the preferred one for maximal portability, while __has_extension is preferred for clang-specific extensions or compatibility with GNU-specific extensions.
So yes, you can use just one of them and not need to check the other. __has_extension includes all of __has_feature along with non-standard extensions (like built-in SIMD vector data types, enumerator attributes, type traits, blocks, address sanitizer, thread sanitizer, memory sanitizer, thread-safety, type-safety, and any other new extensions in the future). And yes, the subject was a bit vague. I first found a bug compiling autogen in clang, then looked through guile where the error was coming from, and that itself is coming from their copy of gnulib, although it might be a bug with autogen or guile still. Are you allowed to use "noreturn" as a parameter name in C? I know that the type is called _Noreturn, but that can get typedef'd before the file is even included, and that appears to cause a problem with clang and not gcc. On 3 November 2013 13:01, Paul Eggert <[email protected]> wrote: > Matt Sicker wrote: > > #ifndef __has_feature > > #define __has_feature(x) 0 > > #endif > > #if __has_feature(c_static_assert) > > ... > > #endif > > Well, obviously that won't work with anything *but* clang, > but before we fix that, the web page in question talks about > both __has_feature(c_static_assert) and __has_extension(c_static_assert). > What's the difference, and why should we care? Also, can we use just > one of those two and not worry about __has_feature(cxx_static_assert) > and __has_extension(cxx_static_assert), even when compiling in C++ > mode? That's the sort of thing that I was talking about > when I wrote that the documentation was unclear. > > This isn't all that high-priority, since gnulib currently *is* > compatible with clang (despite the Subject: line); it's just > that compile-time checking is better with GCC than with Clang > in some cases. > -- Matt Sicker <[email protected]>
