Do these two source file(i.e. include\c_std\cstdlib and include\c_global\cstdlib) serve for different purposes whereas they contain similar content?

[Jonathan Wakely]

On 13/08/20 09:59 -0400, Stephen M. Webb wrote:
>On 2020-08-13 09:53, Jonathan Wakely wrote:
>> On 13/08/20 14:24 +0100, Jonathan Wakely wrote:
>>> On 13/08/20 09:06 -0400, stephen.webb@bregmasoft.ca wrote:
>>>>
>>>> Quoting Jonathan Wakely via Libstdc++ <libstdc++@gcc.gnu.org>:
>>>>
>>>>> On 12/08/20 20:15 +0800, 孙世龙 sunshilong via Libstdc++ wrote:
>>>>>> Hi, list
>>>>>>
>>>>>> These two source files (i.e. include\c_std\cstdlib and
>>>>>> include\c_global\cstdlib) have almost same content.
>>>>>> What is their own role?
>>>>>> Do these two source files serve for different purposes whereas they
>>>>>> contain similar content?
>>>>>
>>>>> You can ignore the c_std one.
>>>>>
>>>>> The headers in that directory are only used if you build gcc with
>>>>> --enable-cheaders=c_std but nobody does that, and they aren't properly
>>>>> maintained any more, and they probably don't work.
>>>>
>>>> To answer the first question, the c_std and c_global set up was to accommodate the fact that some target systems had
>>>> C++ support in their libc system headers by putting symbols in the std:: namespace requiring their symbols to be
>>>> hoisted into the global namespace in the <c...> headers (the c_std strategy), and some had only support for the C
>>>> language and all their symbols were already in the global namespace (the c_global strategy).  I don't believe any of
>>>> the former systems (eg. Solaris 8) are supported by GCC any more.
>>>
>>> But if you look at the include/c_std/ headers, they all pull symbols
>>> from the global namespace into namespace std ... exactly like the
>>> c_global ones.
>>>
>>> I agree that the intended behaviour was what you describe, but I don't
>>> think it ever actually worked, and I don't think any targets using
>>> --enable-cheaders=c_std have ever existed.
>>
>> We also have the include/c/cxxx headers, which assume that the libc
>> headers put the names in *both* the global namespace and namespace
>> std. QNX uses that (see configure.host).
>>
>> We should probably deprecate the --enable-cheaders=c_std configure
>> option and eventually remove those headers. We could make the
>> configure option give an error for c_std unless something like
>> --enable-cheaders-obsolete is also used.
>
>Well, it did work at one time (about 20 years ago) and Solaris 8 was real. I can't account for what happened since then
>but that's the background story. Also, QNX definitely hasn't put symbols in both namespaces for many many years. I have
>absolutely no problem with the split-headers being backed out at this point.

The log for commit af13a7a6ec9a50c39948ee5631a47c29c84fc6d1 says:

             * docs/html/configopts.html: Add c_global information to
             --enable-cheaders. Eventually, "c_std" should mean "C" includes
             that are in namespace std, with optional C++ "C" compatibility
             includes to inject into global scope. And "c_global" should mean
             "C" includes that are in the global namespace, with C++ includes
             injecting into namespace std and no C++ "C" compatibility
             includes.

Note "eventually".

That commit added the c_global headers, but they were identical to the
c_std ones, which were already pulling names from the global namespace
when that was committed in 2006.

Commit 54c1bf7801758caf2ff54917e79a8c239643061c added the c_std
headers in 2002, and they were already doing:

+namespace std 
+{
+  using ::div_t;
+  using ::ldiv_t;
+

Before that the file was called include/c_std/bits/std_cstdlib.h and
it also pulled names from the global namespace into std.

Before that they changed with:

    2001-06-08  Benjamin Kosnik  <bkoz@redhat.com>

             libstdc++/2767
             libstdc++/2989
             libstdc++/2992
             * include/std/*: Add copyright notice.
             * include/c_std/bits/*: Use using statements instead of extern "C".
             * include/c_std/bits/std_cmath.h: Don't overload double versions
             of math functions with __buitin versions, use global version to
             prevent ambiguities. Remove define hacks.
             * include/c_std/bits/std_cwchar.h: Using declarations for "C"
             functions that have changed signatures and std::
             declarations. Remove define hacks.
             * include/c_std/bits/std_cwchar.h: Same, plus remove ambiguous
             __builtins in std::. Remove define hacks.
             * testsuite/17_intro/headers_c.cc: Add tests.
             * testsuite/17_intro/headers_c++.cc: Add test.

Before that there was something going on with "shadow" headers and
_C_legacy namespaces, but I can't really follow that just from diffs
alone and I don't have any recollection how it worked.
Commit 607642b6c2e4e7f7c3953c2748a7d5ac2958f78b seems relevant.

Solaris 8 was supported until 2012, and the c_std headers had already
been pulling things from the global namespace into std for a decade by
that point. I can't reconcile that with the claim that pulling names
from std into the glovbal namespace was needed for Solaris 8 when we
supported it for a decade without doing that. As far as I can tell
(from looking at configure.host and the commits that removed Solaris 8
support) it was using c_model=c_global, like every other target except
QNX, which uses c_model=c.

Solaris *does* have correct C++ declarations in its C headers, e.g.
adds overloads like ::div(long, long) in addition to ::div(int, int).
That's why we check __CORRECT_ISO_CPP_STDLIB_H_PROTO and similar
macros. But those correct C++ declarations are all in the global
namespace and we pull them into std.

I think it may be the case that Solaris does provide <cstdlib>,
<cmath> etc. but we don't use them. We define our own versions of
those headers which include <stdlib.h>, <math.h> etc. and pull names
into std. And we've been doing that for 18+ years, so let's declare
the c_std headers obsolete :-)