[Bug c++/13683] [3.3/3.4 Regression] bogus warning about passing non-PODs through ellipsis

["gdr at integrable-solutions dot net" <gcc-bugzilla at gcc dot gnu dot org>]

------- Additional Comments From gdr at integrable-solutions dot net  2004-01-20 13:55 -------
Subject: Re:  [3.3/3.4 Regression] bogus warning about passing non-PODs through ellipsis

"giovannibajo at libero dot it" <gcc-bugzilla@gcc.gnu.org> writes:

| mmitchel at gcc dot gnu dot org wrote:
| 
| > Yes, the question to me is not "can we change the compiler's behavior"
| > , but "should we?"
| 
| Passing a non-POD object through ellipsis is undefined behaviour *if* the call
| is done. In our situation, there is absolutely no call being performed (nor
| code generated where we abort), so there is no undefined behaviour.

This is a *warning* not an error, and warnings are just about that.
If we knew it were actually undefined, we would probably be issueing
an error.

I can understand your request in the case of sizeof but I do not
understand it as rephrased as above.  How precisely do you define call
being performed or code generated?  

   if (0) {
       pass through ellipsis
   } else {
      do something else
   }

Remember the "0" can come from macro expansion like "HAVE_FEATURE" and
that people compile such codes so as to get as maximum of compiler
check as they can.

(And if you asked me, I consider SFINAE brittle code ;-)

| We're not
| warning of an existing potential issue, because the call will simply never
| happen. We could even argue that the diagnostic is misleading - by saying "the
| code will abort at runtime", we trick the user into believing that there is
| indeed a function call.

We can nitpick on how the actual wording should be, but the basic
issue is not there. 


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13683