M_PI not available with gcc --std=c11 but with --std=gnu11?

Question

I noticed M_PI is unavailable on c11. By looking at /usr/include/math.h I can see M_PI is defined if:

#if !defined(__STRICT_ANSI__) || ((_XOPEN_SOURCE - 0) >= 500)
...
#define M_PI 3.1415...
#endif 

Moreover in the math.h from glibc __STRICT_ANSI__ is replaced with __USE_MISC. I am completely lost with this.

What is the story in between --std=c11 and the constants defined in math.h?

Which libc should I consider on a debian distribution ?

By the way, M_PI is defined in c99 and gnu11...

Answer 1

It's simple: M_PI is not defined in standard C. Provide your own definition if you want to be standard-compliant.

C compilers cannot introduce such constants without breaking legal C programs (the name is not reserved, and could be used as an identifier), and as such, they are only defined as an extension.

GCC 4.9 when used with -std=c99 doesn't define M_PI, but does when used with -std=gnu99

Answer 2

If you just want M_PI while looking for a more comprehensive answer with POSIX / XOPEN feature tests macros, etc., an interim solution is:

#ifndef M_PI
#define M_PI (3.14159265358979323846)
#endif

That's "1.20" format, which is also sufficient for 'round-trip' representation for an 80 bit extended type. double precision is "1.16". For 128-bit quad precision:

#define M_PI (3.14159265358979323846264338327950288)

The "1.35" format for round-trip precision. This means if you want to print out a floating point double, and recover the same value when you read it back, you should use "%+1.16" for printf functions, as so on. You might say that a double doesn't have 17 significant digits, but those digits are not 'junk' if you want to recover a value.

Anyway - there are better resources than this available.

Answer 3

The M_PI macro isn't defined by the C11 standard: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1548.pdf

Therefore, the #if guards are protecting you from problems in case you want to define your own M_PI macro. gcc is doing exactly the right thing. The standard headers shouldn't arbitrarily define macros that are not in the standard.