This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug libstdc++/70722] include_next in cmath skips user-defined wrapper
- From: "redi at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Thu, 21 Jul 2016 11:47:55 +0000
- Subject: [Bug libstdc++/70722] include_next in cmath skips user-defined wrapper
- Auto-submitted: auto-generated
- References: <bug-70722-4@http.gcc.gnu.org/bugzilla/>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70722
--- Comment #12 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Nadav Har'El from comment #10)
> There is nothing "holy" about glibc, and nothing "broken" about wanting to
> replace it (or, as Firefox did, only a part of it). Sure, the replacement
> needs to be 100% compatible with glibc, and if it isn't, the replacement
> needs to be fixed (e.g., I just fixed this
> https://github.com/cloudius-systems/osv/issues/770 and didn't come
> complaining to the libstdc++ project).
>
> HOWEVER, in this case, the projects in question (Firefox, OSv, and probably
> more to come) did nothing incorrect or incompatible in their glibc
> replacement. Their only "sin" was the order of the header files.
Are you sure about that?
17.6.4.4 Headers [alt.headers]
If a file with a name equivalent to the derived file name for one of the C++
standard library headers is not provided as part of the implementation, and
a file with that name is placed in any of the standard places for a source
file to be included (16.2), the behavior is undefined.
> I still don't understand why the glibc header files could not have been
> improved to accommodate also the C++ standard (and I have no idea what the
> issues were) instead of needing to have copies of the same header file in
> both libstdc++ and glibc.
Not everybody uses glibc.
The change is documented at https://gcc.gnu.org/gcc-6/porting_to.html so if you
want to continue playing games with undefined behaviour then it's your job to
fix it.