Feature Conditional for M_PI

Feature Conditional for M_PI

[Joel Sherrill]

Hi

I was porting some code from Linux to Cygwin and came across this. M_PI in
math.h is defined by POSIX as part of XSI. It does not appear to be part of
C99 or C++03.  I have this cut down to show the problem:

==========================
#include <math.h>

double pi = M_PI;
==========================

And this script to try various feature defines and compilers:

===========================
GCC=${GCC:-g++}

${GCC} -c m.c
${GCC} -D_XOPEN_SOURCE=700 -c m.c
${GCC} -D_POSIX_C_SOURCE=200809L -c m.c
${GCC} -D_XOPEN_SOURCE=700 -c -D_POSIX_C_SOURCE=200809L -c m.c
===========================

All of those compiler invocations work on Linux but the third one does not
work on Cygwin or RTEMS which use newlib.

Is the proper thing to do to add  -D_XOPEN_SOURCE=700 when compiling this
program?

Just curious if Linux is defining _XOPEN_SOURCE by default and newlib
doesn't. Not sure what's the right answer. So asking.

Thanks

--joel

Re: Feature Conditional for M_PI

[Corinna Vinschen]

On Aug 31 10:10, Joel Sherrill wrote:
> Hi
> 
> I was porting some code from Linux to Cygwin and came across this. M_PI in
> math.h is defined by POSIX as part of XSI. It does not appear to be part of
> C99 or C++03.  I have this cut down to show the problem:
> 
> ==========================
> #include <math.h>
> 
> double pi = M_PI;
> ==========================
> 
> And this script to try various feature defines and compilers:
> 
> ===========================
> GCC=${GCC:-g++}
> 
> ${GCC} -c m.c
> ${GCC} -D_XOPEN_SOURCE=700 -c m.c
> ${GCC} -D_POSIX_C_SOURCE=200809L -c m.c
> ${GCC} -D_XOPEN_SOURCE=700 -c -D_POSIX_C_SOURCE=200809L -c m.c
> ===========================
> 
> All of those compiler invocations work on Linux but the third one does not
> work on Cygwin or RTEMS which use newlib.
> 
> Is the proper thing to do to add  -D_XOPEN_SOURCE=700 when compiling this
> program?
> 
> Just curious if Linux is defining _XOPEN_SOURCE by default and newlib
> doesn't.

In glibc's math.h, M_PI is guarded with

  #if defined __USE_MISC || defined __USE_XOPEN

In newlib, it's guarded with

  #if __BSD_VISIBLE || __XSI_VISIBLE

Note that this is identical to the guards on at least FreeBSD.

In both cases, newlib as well as glibc, "MISC" is defined by default,
but "BSD" isn't.  That's why your 3rd invocation fails on BSDs and
newlib/Cygwin, but not on Linux.

> Not sure what's the right answer. So asking.

Corinna

Re: Feature Conditional for M_PI

[Corinna Vinschen]

On Aug 31 17:27, Corinna Vinschen via Newlib wrote:
> On Aug 31 10:10, Joel Sherrill wrote:
> > Hi
> > 
> > I was porting some code from Linux to Cygwin and came across this. M_PI in
> > math.h is defined by POSIX as part of XSI. It does not appear to be part of
> > C99 or C++03.  I have this cut down to show the problem:
> > 
> > ==========================
> > #include <math.h>
> > 
> > double pi = M_PI;
> > ==========================
> > 
> > And this script to try various feature defines and compilers:
> > 
> > ===========================
> > GCC=${GCC:-g++}
> > 
> > ${GCC} -c m.c
> > ${GCC} -D_XOPEN_SOURCE=700 -c m.c
> > ${GCC} -D_POSIX_C_SOURCE=200809L -c m.c
> > ${GCC} -D_XOPEN_SOURCE=700 -c -D_POSIX_C_SOURCE=200809L -c m.c
> > ===========================
> > 
> > All of those compiler invocations work on Linux but the third one does not
> > work on Cygwin or RTEMS which use newlib.
> > 
> > Is the proper thing to do to add  -D_XOPEN_SOURCE=700 when compiling this
> > program?
> > 
> > Just curious if Linux is defining _XOPEN_SOURCE by default and newlib
> > doesn't.
> 
> In glibc's math.h, M_PI is guarded with
> 
>   #if defined __USE_MISC || defined __USE_XOPEN
> 
> In newlib, it's guarded with
> 
>   #if __BSD_VISIBLE || __XSI_VISIBLE
> 
> Note that this is identical to the guards on at least FreeBSD.
> 
> In both cases, newlib as well as glibc, "MISC" is defined by default,
> but "BSD" isn't.  That's why your 3rd invocation fails on BSDs and
> newlib/Cygwin, but not on Linux.

Huh, wait!  I bet this does *not* fail on BSD because BSD very likely
defines __BSD_VISIBLE by default.

We could move the math.h constants to __MISC_VISIBLE || __XSI_VISIBLE,
perhaps that makes more sense for us?


Corinna

Re: Feature Conditional for M_PI

[Joel Sherrill]

On Mon, Aug 31, 2020 at 10:30 AM Corinna Vinschen via Newlib <
newlib@sourceware.org> wrote:

> On Aug 31 17:27, Corinna Vinschen via Newlib wrote:
> > On Aug 31 10:10, Joel Sherrill wrote:
> > > Hi
> > >
> > > I was porting some code from Linux to Cygwin and came across this.
> M_PI in
> > > math.h is defined by POSIX as part of XSI. It does not appear to be
> part of
> > > C99 or C++03.  I have this cut down to show the problem:
> > >
> > > ==========================
> > > #include <math.h>
> > >
> > > double pi = M_PI;
> > > ==========================
> > >
> > > And this script to try various feature defines and compilers:
> > >
> > > ===========================
> > > GCC=${GCC:-g++}
> > >
> > > ${GCC} -c m.c
> > > ${GCC} -D_XOPEN_SOURCE=700 -c m.c
> > > ${GCC} -D_POSIX_C_SOURCE=200809L -c m.c
> > > ${GCC} -D_XOPEN_SOURCE=700 -c -D_POSIX_C_SOURCE=200809L -c m.c
> > > ===========================
> > >
> > > All of those compiler invocations work on Linux but the third one does
> not
> > > work on Cygwin or RTEMS which use newlib.
> > >
> > > Is the proper thing to do to add  -D_XOPEN_SOURCE=700 when compiling
> this
> > > program?
> > >
> > > Just curious if Linux is defining _XOPEN_SOURCE by default and newlib
> > > doesn't.
> >
> > In glibc's math.h, M_PI is guarded with
> >
> >   #if defined __USE_MISC || defined __USE_XOPEN
> >
> > In newlib, it's guarded with
> >
> >   #if __BSD_VISIBLE || __XSI_VISIBLE
> >
> > Note that this is identical to the guards on at least FreeBSD.
> >
> > In both cases, newlib as well as glibc, "MISC" is defined by default,
> > but "BSD" isn't.  That's why your 3rd invocation fails on BSDs and
> > newlib/Cygwin, but not on Linux.
>

Thanks for poking at the BSDs. I went and tried that also.

>
> Huh, wait!  I bet this does *not* fail on BSD because BSD very likely
> defines __BSD_VISIBLE by default.
>

The third case fails on FreeBSD 12 as well.

>
> We could move the math.h constants to __MISC_VISIBLE || __XSI_VISIBLE,
> perhaps that makes more sense for us?
>

https://github.com/freebsd/freebsd/blob/master/lib/msun/src/math.h#L143 has
this:

 #if __BSD_VISIBLE || __XSI_VISIBLE

which matches your expectations on their wrapper but not the outcome.
I guess they don't define __BSD_VISIBLE by default.

If we want newlib to follow glibc, then this should change to MISC but
I certainly would want to hear from some of the standards folks who
are on this list. :)

--joel

>
>
> Corinna
>
>

Re: Feature Conditional for M_PI

[Corinna Vinschen]

On Aug 31 10:50, Joel Sherrill wrote:
> On Mon, Aug 31, 2020 at 10:30 AM Corinna Vinschen via Newlib <
> newlib@sourceware.org> wrote:
> 
> > On Aug 31 17:27, Corinna Vinschen via Newlib wrote:
> > > On Aug 31 10:10, Joel Sherrill wrote:
> > > > Hi
> > > >
> > > > I was porting some code from Linux to Cygwin and came across this.
> > M_PI in
> > > > math.h is defined by POSIX as part of XSI. It does not appear to be
> > part of
> > > > C99 or C++03.  I have this cut down to show the problem:
> > > >
> > > > ==========================
> > > > #include <math.h>
> > > >
> > > > double pi = M_PI;
> > > > ==========================
> > > >
> > > > And this script to try various feature defines and compilers:
> > > >
> > > > ===========================
> > > > GCC=${GCC:-g++}
> > > >
> > > > ${GCC} -c m.c
> > > > ${GCC} -D_XOPEN_SOURCE=700 -c m.c
> > > > ${GCC} -D_POSIX_C_SOURCE=200809L -c m.c
> > > > ${GCC} -D_XOPEN_SOURCE=700 -c -D_POSIX_C_SOURCE=200809L -c m.c
> > > > ===========================
> > > >
> > > > All of those compiler invocations work on Linux but the third one does
> > not
> > > > work on Cygwin or RTEMS which use newlib.
> > > >
> > > > Is the proper thing to do to add  -D_XOPEN_SOURCE=700 when compiling
> > this
> > > > program?
> > > >
> > > > Just curious if Linux is defining _XOPEN_SOURCE by default and newlib
> > > > doesn't.

Actually, Yaakov pointed out on IRC that this is a C++ problem on Linux.
You're running the above test with g++.  If you perform the third test
with gcc on Linux:

  gcc -D_POSIX_C_SOURCE=200809L -c m.c

you'll get the same error as on newlib and FreeBSD:

m.c: In function ‘main’:
m.c:8:15: error: ‘M_PI’ undeclared (first use in this function)
    8 |   double pi = M_PI;
          |               ^~~~
	  m.c:8:15: note: each undeclared identifier is reported only once for each function it appears in

The problem in glibc and/or g++ is that this does *not* occur when
building with g++.


Corinna

Re: Feature Conditional for M_PI

[Joel Sherrill]

On Mon, Aug 31, 2020 at 3:05 PM Corinna Vinschen via Newlib <
newlib@sourceware.org> wrote:

> On Aug 31 10:50, Joel Sherrill wrote:
> > On Mon, Aug 31, 2020 at 10:30 AM Corinna Vinschen via Newlib <
> > newlib@sourceware.org> wrote:
> >
> > > On Aug 31 17:27, Corinna Vinschen via Newlib wrote:
> > > > On Aug 31 10:10, Joel Sherrill wrote:
> > > > > Hi
> > > > >
> > > > > I was porting some code from Linux to Cygwin and came across this.
> > > M_PI in
> > > > > math.h is defined by POSIX as part of XSI. It does not appear to be
> > > part of
> > > > > C99 or C++03.  I have this cut down to show the problem:
> > > > >
> > > > > ==========================
> > > > > #include <math.h>
> > > > >
> > > > > double pi = M_PI;
> > > > > ==========================
> > > > >
> > > > > And this script to try various feature defines and compilers:
> > > > >
> > > > > ===========================
> > > > > GCC=${GCC:-g++}
> > > > >
> > > > > ${GCC} -c m.c
> > > > > ${GCC} -D_XOPEN_SOURCE=700 -c m.c
> > > > > ${GCC} -D_POSIX_C_SOURCE=200809L -c m.c
> > > > > ${GCC} -D_XOPEN_SOURCE=700 -c -D_POSIX_C_SOURCE=200809L -c m.c
> > > > > ===========================
> > > > >
> > > > > All of those compiler invocations work on Linux but the third one
> does
> > > not
> > > > > work on Cygwin or RTEMS which use newlib.
> > > > >
> > > > > Is the proper thing to do to add  -D_XOPEN_SOURCE=700 when
> compiling
> > > this
> > > > > program?
> > > > >
> > > > > Just curious if Linux is defining _XOPEN_SOURCE by default and
> newlib
> > > > > doesn't.
>
> Actually, Yaakov pointed out on IRC that this is a C++ problem on Linux.
> You're running the above test with g++.  If you perform the third test
> with gcc on Linux:
>
>   gcc -D_POSIX_C_SOURCE=200809L -c m.c
>
> you'll get the same error as on newlib and FreeBSD:
>
> m.c: In function ‘main’:
> m.c:8:15: error: ‘M_PI’ undeclared (first use in this function)
>     8 |   double pi = M_PI;
>           |               ^~~~
>           m.c:8:15: note: each undeclared identifier is reported only once
> for each function it appears in
>
> The problem in glibc and/or g++ is that this does *not* occur when
> building with g++.
>

Thanks. I was building with g++ because the code this came up in was C++.
In the application, I just defined the proper thing to make it visible.

Was this the right thing to do? Or is there something else wrong? Honestly,
the odd C library things that happen from C++ is often hard to explain.

--joel



>
>
> Corinna
>
>

Re: Feature Conditional for M_PI

[Yaakov Selkowitz]

On Mon, 2020-08-31 at 16:19 -0500, Joel Sherrill via Newlib wrote:
> On Mon, Aug 31, 2020 at 3:05 PM Corinna Vinschen via Newlib <
> newlib@sourceware.org> wrote:
> 
> > On Aug 31 10:50, Joel Sherrill wrote:
> > > On Mon, Aug 31, 2020 at 10:30 AM Corinna Vinschen via Newlib <
> > > newlib@sourceware.org> wrote:
> > > 
> > > > On Aug 31 17:27, Corinna Vinschen via Newlib wrote:
> > > > > On Aug 31 10:10, Joel Sherrill wrote:
> > > > > > Hi
> > > > > > 
> > > > > > I was porting some code from Linux to Cygwin and came across this.
> > > > M_PI in
> > > > > > math.h is defined by POSIX as part of XSI. It does not appear to be
> > > > part of
> > > > > > C99 or C++03.  I have this cut down to show the problem:
> > > > > > 
> > > > > > ==========================
> > > > > > #include <math.h>
> > > > > > 
> > > > > > double pi = M_PI;
> > > > > > ==========================
> > > > > > 
> > > > > > And this script to try various feature defines and compilers:
> > > > > > 
> > > > > > ===========================
> > > > > > GCC=${GCC:-g++}
> > > > > > 
> > > > > > ${GCC} -c m.c
> > > > > > ${GCC} -D_XOPEN_SOURCE=700 -c m.c
> > > > > > ${GCC} -D_POSIX_C_SOURCE=200809L -c m.c
> > > > > > ${GCC} -D_XOPEN_SOURCE=700 -c -D_POSIX_C_SOURCE=200809L -c m.c
> > > > > > ===========================
> > > > > > 
> > > > > > All of those compiler invocations work on Linux but the third one
> > does
> > > > not
> > > > > > work on Cygwin or RTEMS which use newlib.
> > > > > > 
> > > > > > Is the proper thing to do to add  -D_XOPEN_SOURCE=700 when
> > compiling
> > > > this
> > > > > > program?
> > > > > > 
> > > > > > Just curious if Linux is defining _XOPEN_SOURCE by default and
> > newlib
> > > > > > doesn't.
> > 
> > Actually, Yaakov pointed out on IRC that this is a C++ problem on Linux.
> > You're running the above test with g++.  If you perform the third test
> > with gcc on Linux:
> > 
> >   gcc -D_POSIX_C_SOURCE=200809L -c m.c
> > 
> > you'll get the same error as on newlib and FreeBSD:
> > 
> > m.c: In function ‘main’:
> > m.c:8:15: error: ‘M_PI’ undeclared (first use in this function)
> >     8 |   double pi = M_PI;
> >           |               ^~~~
> >           m.c:8:15: note: each undeclared identifier is reported only once
> > for each function it appears in
> > 
> > The problem in glibc and/or g++ is that this does *not* occur when
> > building with g++.
> > 
> 
> Thanks. I was building with g++ because the code this came up in was C++.
> In the application, I just defined the proper thing to make it visible.
> 
> Was this the right thing to do? Or is there something else wrong? Honestly,
> the odd C library things that happen from C++ is often hard to explain.

Yes, that is the correct solution.

Unfortunately, the work to automatically make visible the symbols
required by various C++ standards hasn't been done in glibc, therefore
on Linux targets, G++ defines _GNU_SOURCE which enables everything.  To
that end, newlib/cygwin are actually more correct than glibc, but this
is the price for being correct.

Fixing this in glibc and g++ has been on my to-do wish list since the
newlib/cygwin FTMs were finished, but I just haven't had the time.

-- 
Yaakov Selkowitz
Senior Software Engineer - Platform Enablement
Red Hat,
Inc.