Fix/gcc9 cpp17 support

[sodero]

These changes in combination with an updated clib2 enables full C++11/17/2a support. It's of course not optimal to use a clib2 fork, but I figured it's better than to fork both adtools and clib2. The updated clib2 also paves the way for integrating the patchset for gcc10 that currently lives in my fork only.

This solves #96 #94 #93 #91

[sba1]

Could you remove the addition of these lines from the original patch? That is, adding these lines in the same patch series just to remove them seems to redudant. Also note that the #undef is needed also for newlib (your comment just talks about newlib). Generally, the #undef is only a temporary solution, that state should be reflected in the patch/comment.

[sba1]

Sorry, I found out that I did not submit the review. Not sure if you saw it.

[sodero]

I'll fix that. I wasn't sure how much 'paper trail' to produce. When looking at the original patch (0011) my guess is that we can skip it completely, the new newlib (!?) implements strtold and so does the proposed clib2.

[sodero]

I forgot; I think newlib behaves the way it should. It hides everything >C89 when __STRICT_ANSI__ is set, just like glibc The question is why __STRICT_ANSI__ is set during configuration. Either way, just like you say, the undef is temporary, but I don't think newer versions of newlib will solve the problem.

[sba1]

IIRC __STRICT_ANSI__ "just" hides any gnu extensions of the C standard at the currently selected C level in the sense of the synax of the language. I'm not sure if shall have implications of the defined functions or at least it should not be the only parameter. This probably was a workaround because newlib defined some function in sope of __STRICT_ANSI__ that were present in c11, but c11 implies __STRICT_ANSI__ and so configure did not produce the desired results. That does not mean that the behaviour is the expected one but this is how I observed it.

[sba1]

I'll fix that. I wasn't sure how much 'paper trail' to produce. When looking at the original patch (0011) my guess is that we can skip it completely, the new newlib (!?) implements strtold and so does the proposed clib2.

At least for newlib, we have to support the older version for quite a while until new newlib and SDK is circulated.

[sodero]

IIRC STRICT_ANSI "just" hides any gnu extensions of the C standard at the currently selected C level in the sense of the synax of the language. I'm not sure if shall have implications of the defined functions or at least it should not be the only parameter.

I don't think it's just about extensions. From the gcc documentation:

__STRICT_ANSI__
GCC defines this macro if and only if the -ansi switch, or a -std switch specifying strict conformance to some version of ISO C, was specified when GCC was invoked. It is defined to `1'. This macro exists primarily to direct GNU libc's header files to restrict their definitions to the minimal set found in the 1989 C standard.

There's always something hidden in there to cause confusion, 'primarily', what other use cases are there? :-)

At least for newlib, we have to support the older version for quite a while until new newlib and SDK is circulated.

Yes, bits and pieces from all over the place is not a good idea. I really don't understand why they don't open up newlib.

[sba1]

IIRC STRICT_ANSI "just" hides any gnu extensions of the C standard at the currently selected C level in the sense of the synax of the language. I'm not sure if shall have implications of the defined functions or at least it should not be the only parameter.

I don't think it's just about extensions. From the gcc documentation:

STRICT_ANSI
GCC defines this macro if and only if the -ansi switch, or a -std switch specifying strict conformance to some version of ISO C, was specified when GCC was invoked. It is defined to `1'. This macro exists primarily to direct GNU libc's header files to restrict their definitions to the minimal set found in the 1989 C standard.

There's always something hidden in there to cause confusion, 'primarily', what other use cases are there? :-)

Yes, I'm aware of this but following my observation I ignored it. I always had the feeling this was old documentation (especially the last part, the first part IMO holds true) because it does not reflect what gcc does at the moment. My bet was is that the usage of the macro was extended and the last part was just an example. One would have too look at the history of gcc and the gnu libc to see when this confusion started. My observation was based on:

 $ gcc -std=c++17 -x c++ -dM -E - < /dev/null | grep STRICT

or

 $ gcc -std=c11 -dM -E - < /dev/null | grep STRICT

in contrast to

 $ gcc -std=gnu++17 -x c++ -dM -E - < /dev/null | grep STRICT

or

 $ gcc -std=gnu11 -dM -E - < /dev/null | grep STRICT

(on an amd64 glibc-based linux system).

Note that apparently __STRICT_ANSI___ is also defined in C++. All in all I believe that the real fix (if you want to call it that way) should be done in the respective clib files, but temporarily it cal be addressed via patches.

[sodero]

Interesting, thanks for the info.

[sodero]

I fixed the __STRICT_ANSI__ issue and bumped clib2 while I was at it. It contains a couple of fixes and some improvements in C99 compatibility, tgmath, iso646 and partial wchar support.

[kas1e]

So, seems Sebastian has for real no more time for all that, if it takes months, and it means it better to works now on separate forks.

[sba1]

Sorry, I missed it. As gcc 9 support is already present and the merge significantly improves it, I merged it.