Commit df5582fa authored by Martin Dørum's avatar Martin Dørum

small changes

parent 931ce55f
......@@ -14,7 +14,7 @@ most of these quirks have good technical or practical reasons.
## Compilers lie about what version of the standard they support
There's a handy macro, called `__STDC_VERSION__`, which describes the version
of the C standard the implementation conforms to. We can check
of the C standard your C implementation conforms to. We can check
`#if (__STDC_VERSION__ >= 201112L)` to check if our C implementaion confirms to
C11 or higher (C11 was published in December 2011, hence `2011 12`). That's
really useful if, say, you're a library author and
......@@ -45,7 +45,8 @@ versions of GCC.
The solution still seems relatively simple; just don't use -std=c11.
More recent compilers default to C11 anyways,
and there's no widely used compiler that I know of
which will set `__STDC_VERSION__` to C11 without actually supporting all of C11.
which will default to setting `__STDC_VERSION__` to C11
without actually supporting all of C11.
That works well enough, but there's one problem:
GCC 4.9 supports all of C11 just fine, but only if we give it `-std=c11`.
GCC 4.9 also seems to be one of those annoyingly widespread versions of GCC,
......@@ -55,8 +56,7 @@ macros which rely on `_Generic` work in GCC 4.9.
Again, the solution seems obvious enough, if a bit ugly:
if the compiler is GCC, we only use `_Genric` if the GCC version is 4.9 or
greater and `__STDC_VERSION__` is C11.
If the compiler is not GCC, we just trust it if it says it supports C11
(or we could potentially add more special cases later).
If the compiler is not GCC, we just trust it if it says it supports C11.
This should in theory work perfectly:
``` C
......@@ -72,17 +72,18 @@ This should in theory work perfectly:
```
Our new `IS_C11` macro should now always be defined if we can use `_Generic`
and always not be defined when we can's use `_Generic`, right?
and always not be defined when we can't use `_Generic`, right?
Wrong. It turns out that in their quest to support code written for GCC, Clang
also defines the `__GNUC__`, `__GNUC_MINOR__`, and `__GNUC_PATCHLEVEL__`
macros, specifically to fool code which checks for GCC into thinking Clang is
GCC. However, it doesn't really go far enough; it defines the `__GNUC_*`
variables to correspond to the the version of _clang_, not the version of GCC
which Clang claims to imitate.
GCC.
However, it doesn't really go far enough;
it defines the `__GNUC_*` variables to correspond to the the version of _clang_,
not the version of GCC which Clang claims to imitate.
Clang gained support for C11 in 3.6, but using our code,
we would conclude that it doesn't support C11 because `__GNUC__`
would be 3 and `__GNUC_MINOR__` would be 6.
is 3 and `__GNUC_MINOR__` is 6.
We can solve this by adding a special case for when `__clang__` is defined:
``` C
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment