This is the mail archive of the gcc-patches@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]

Re: [C++ PATCH] Allow some function pointer conversions


Mark Mitchell <mark@codesourcery.com> writes:

| Nathan Sidwell wrote:
| 
| > This patch implements the smallest parts of DR195 that I think are
| > appropriate right now.  DR195 is in drafting, but has been kicking around
| > for several years. The patch fixes the regressions caused by Mark's patch
| > for 14035 in the C++ testsuite.
| >
| > The new testcase g++.dg/expr/cast2.C, still fails.  It think it
| > should probably be removed as the testcase with this patch is doing
| > more complete checking.  Also I changed g++.old-deja/g++.mike/p10148.C.
| > I couldn't really see the point of the c-cast there -- it was converting
| > the function pointer to a base (of the current class) pointer.  I suspect
| > some parens might have been missed.
| >
| > I've not documented the casts this patch permits, but will do so once
| > we've agreed on the desired semantics. Specifically, this patch permits
| >
| > *) pointer-to-function to be explicitly converted to pointer-to-void,
| > provided there is no loss of precision.
| > *) pointer-to-void can be explicitly converted to pointer-to-function,
| > regardless of precision loss.  The reason for a lack of precision check
| > here, is so one can convert a function-pointer to a void-pointer and back
| > again, so long as the void-pointer has at least as many bits.
| >
| > DR195 does not single out pointer-to-void, but I consider void pointers
| > to be a reasonable restriction right now.  We can always relax it later.
| 
| I think that if we want to implement DR195, I'd be happiest if we just
| removed the diagnostic.  (Before my patch, things were inconsistent;
| we issued a pedwarn for reinterpret_cast, but not for a C-style cast.
| I made the two match up.) I think that we could just remove the
| diangostic altogether to implement DR195.
| 
| We could also turn it into a warning, which might be the most
| conservative choice; we would still conform to TC1, but also implement
| DR195.

If we believe we really want to implement DR195, then I would
recommend we do not remove the diagnostic, but make it a warning.
Jason?

-- Gaby


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