This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug libstdc++/70722] include_next in cmath skips user-defined wrapper


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.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]