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++: delete of incomplete type is undefined, not ill-formed


On May 16, 2002, Gabriel Dos Reis <gdr@codesourcery.com> wrote:

> Alexandre Oliva <aoliva@redhat.com> writes:
> | [1  <text/plain>]
> | Once again, I'm not sure I can publish the testcase I got from the
> | customer, so I'll describe the problem.  When we delete a variable
> | whose type is pointer-to-incomplete-type (say, a forward-declared
> | class type), we emit an error message.  However, [expr.delete]/5 says
> | this invokes undefined behavior,

> I don't think it says exactly that.  THere are the exact words:

>   If the object being deleted has incomplete class type at the point
>   of deletion *and* the complete class has a non-trivial destructor or a
>   deallocation function, the behavior is undefined. 

Hmm...  You're right, I omitted a bit of info in my description of the
problem.  Sorry.

Anyway, it only means that my patch introduces the well-defined
behavior for the cases in which it is well-defined (i.e., not run the
destructor since it's trivial and call the deallocation function).
What it does in the undefined-behavior case doesn't matter, but since
there's no way to tell whether behavior is defined or not in case the
class type is incomplete, the only safe thing to do is to assume
behavior is defined and do as I suggest.

> I'm not sure I'm confortable with your proposed patch.  What are the
> concrte wins?

Other than Standard compliance, the only win I can think of is that,
if you use `delete ptr_to_incomplete_POD_type;', it works as expected,
even though there's no way the compiler can tell whether the said POD
type is actually POD, since it's incomplete in that translation unit.

> For that matter:

>   1.3.12 undefined behavior 

Thanks for reminding me that undefined behavior can indeed abort the
translation of the program.  I keep forgetting this :-(

Anyway, in this case, we can't tell whether behavior is defined or
undefined, so we have to assume it is and do the best we can.

If the patch I proposed made the compiler object to the construct
claiming it was undefined in general, it would be wrong.  But it just
warns that the type is incomplete, which leaves it up to the
programmer to figure out whether this will invoke behave correctly or
not.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer


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