Mailing List Archive: Nasty DESTROY in xsubpp

Nasty DESTROY in xsubpp

Dec 19, 1995, 4:37 PM

Post #1 of 3 (249 views)

Today I wrote

void
DESTROY(r)
regexp *r

and found that it inserted

delete THIS;

Note that my code did not even sleep close to C++, so both delete (and
whitespace) and THIS are undefined.

Is this a desired behaviour? I expected just
DESTROY(r);

Ilya

P.S. I had

#define DESTROY regfree

at the start, and

regexp * T_PTROBJ

in typemap. I think the described behaviour is not bad for _some_ T_*,
but not for T_PTROBJ.

Re: Nasty DESTROY in xsubpp [ In reply to ]

roehrich at cray

Dec 19, 1995, 5:15 PM

Post #2 of 3 (240 views)

Permalink

>From: Ilya Zakharevich <ilya@math.ohio-state.edu>
>
>Today I wrote
>
>void
>DESTROY(r)
>regexp *r
>
>and found that it inserted
>
> delete THIS;

I can reproduce it with xsubpp 1.925. It's doing that when a CODE: block
isn't supplied, even if it doesn't look like a C++ method. That's not a
desirable feature :) It looks like an old bug, one which looks like DESTROY
was always expected to be followed by PPCODE: or CODE:.

Here's the fix, against 1.925. I've tested it with the case you've given and
with my cookbook of C and C++ extensions. This patch says DESTROY can only
be treated like a C++ destructor if it was declared with a class name.

Dean

*** lib/ExtUtils/xsubpp Tue Dec 19 18:13:13 1995
--- ../patches/xsubpp Tue Dec 19 18:03:41 1995
***************
*** 715,721 ****
print "\tPUTBACK;\n\treturn;\n";
} elsif (check_keyword("CODE")) {
&print_section;
! } elsif ($func_name eq "DESTROY") {
print "\n\t";
print "delete THIS;\n";
} else {
--- 715,721 ----
print "\tPUTBACK;\n\treturn;\n";
} elsif (check_keyword("CODE")) {
&print_section;
! } elsif (defined($class) and $func_name eq "DESTROY") {
print "\n\t";
print "delete THIS;\n";
} else {

Re: Nasty DESTROY in xsubpp [ In reply to ]

pmarquess at bfsec

Dec 20, 1995, 9:24 AM

Post #3 of 3 (243 views)

Permalink

From: Dean Roehrich <roehrich@cray.com>
>
> >From: Ilya Zakharevich <ilya@math.ohio-state.edu>
> >
> >Today I wrote
> >
> >void
> >DESTROY(r)
> >regexp *r
> >
> >and found that it inserted
> >
> > delete THIS;
>
> I can reproduce it with xsubpp 1.925. It's doing that when a CODE: block
> isn't supplied, even if it doesn't look like a C++ method. That's not a
> desirable feature :) It looks like an old bug, one which looks like DESTROY
> was always expected to be followed by PPCODE: or CODE:.
>
> Here's the fix, against 1.925. I've tested it with the case you've given and
> with my cookbook of C and C++ extensions. This patch says DESTROY can only
> be treated like a C++ destructor if it was declared with a class name.

Thanks guys.

I'll include the fix with the next xsubpp patch.

Paul