[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Incompatibilities with clang.

From: Matt Sicker
Subject: Re: Incompatibilities with clang.
Date: Sun, 3 Nov 2013 13:15:50 -0600

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 <address@hidden> 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 <address@hidden>

reply via email to

[Prev in Thread] Current Thread [Next in Thread]