This is the mail archive of the
mailing list for the libstdc++ project.
Re: [PATCH] detect incompatible aliases (PR c/81854)
- From: Martin Sebor <msebor at gmail dot com>
- To: Joseph Myers <joseph at codesourcery dot com>
- Cc: Gcc Patch List <gcc-patches at gcc dot gnu dot org>, Jonathan Wakely <jwakely at redhat dot com>, libstdc++ <libstdc++ at gcc dot gnu dot org>
- Date: Mon, 18 Sep 2017 15:21:04 -0600
- Subject: Re: [PATCH] detect incompatible aliases (PR c/81854)
- Authentication-results: sourceware.org; auth=none
- References: <firstname.lastname@example.org> <alpine.DEB.email@example.com>
On 09/12/2017 10:17 AM, Joseph Myers wrote:
On Thu, 17 Aug 2017, Martin Sebor wrote:
+ || (prototype_p (t1)
+ && prototype_p (t2)
+ && !types_compatible_p (t1, t2))))
Why the restriction to prototyped types? I'd expect a warning for an
alias between unprototyped functions of types int () and void (), for
example. Or for an alias between void () and void (char), as a function
with a char argument is not compatible with a non-prototype function in C.
Is this an issue with the problem being diagnosed at a point where the
langhooks for language-specific type compatibility rules aren't available?
If that's preventing diagnosing incompatibility involving unprototyped
functions, then the patch is OK.
It's meant as an escape hatch. It allows declaring compatibility
symbols, for example by the libstdc++ _GLIBCXX_3_4_SYMVER macro
defined in libstdc++-v3/src/c++98/compatibility.cc. The macro is
used to declare compatibility functions of all sorts of incompatible
types. The originally posted patch had libstdc++ disable the warning
for the file with the symbols but Jonathan preferred this solution.
It could perhaps be tightened up to detect some of the cases on your
list but I'm not sure it's worth the effort and added complexity.
Let me know if you feel differently (or have a different suggestion),
otherwise I will go ahead and commit the patch as is.