[rt.cpan.org #11748] Inline::CPP config gets lost because of Inline::C bug
Wed May 08 22:45:09 2013: Request 11748 was acted upon. Transaction: Correspondence added by SISYPHUS Queue: Inline Subject: Inline::CPP config gets lost because of Inline::C bug Broken in: (no value) Severity: Important Owner: Nobody Requestors: nick_...@pisem.net Status: open Ticket URL: https://rt.cpan.org/Ticket/Display.html?id=11748 Marking as resolved. Fixed in Inline-0.53 (which was released to CPAN on 30th April 2013). Cheers, Rob
[rt.cpan.org #11748] Inline::CPP config gets lost because of Inline::C bug
Tue Apr 23 23:49:15 2013: Request 11748 was acted upon.
Transaction: Correspondence added by SISYPHUS
Queue: Inline
Subject: Inline::CPP config gets lost because of Inline::C bug
Broken in: (no value)
Severity: Important
Owner: Nobody
Requestors: nick_...@pisem.net
Status: open
Ticket URL: https://rt.cpan.org/Ticket/Display.html?id=11748
On Sat Apr 20 02:53:07 2013, iang wrote:
I think the fault is in Inline::CPP, not Inline::C.
Yes, I now think that *is* right.
If Inline::CPP
generates typemap data (if $typemap has non-zero length in
Inline::CPP::write_typemap) then Inline::CPP::validate is called
with the generated TYPEMAP data passed, but this calls
Inline::C::validate, which sets $o-{ILSM}{MAKEFILE}{INC}, unless
$o-UNTAINT is set.
[snip]
Part of the issue is that when validating TYPEMAP, all the other
options are not passed to Inlince::C::validate. The initialization
there sets INC and the previously passed value is not appended
because it is not passed, only the TYPEMAP is passed.
Seems to me that Inline::C::validate is not really designed to receive that set
of data, and Inline::CPP should probably not be passing that set of data to it.
Nevertheless, it can apparently be easily fixed by applying the suggested
change to Inline::C::validate - so I'll go with the original fix.
A version of Inline containing this fix has been uploaded to CPAN as
Inline-0.52_02. Unless, in the meantine, there's an issue found with
Inline-0.52_02, it will be released as Inline-0.53 early next week.
Thanks again, Ian, for for the digging and the demo case.
Cheers,
Rob
[rt.cpan.org #11748] Inline::CPP config gets lost because of Inline::C bug
Sat Apr 20 02:53:07 2013: Request 11748 was acted upon.
Transaction: Correspondence added by iang
Queue: Inline
Subject: Inline::CPP config gets lost because of Inline::C bug
Broken in: (no value)
Severity: Important
Owner: Nobody
Requestors: nick_...@pisem.net
Status: open
Ticket URL: https://rt.cpan.org/Ticket/Display.html?id=11748
On Mon Jun 29 19:24:59 2009, SISYPHUS wrote:
On Fri Mar 04 06:12:48 2005, guest wrote:
It had seemed that Inline::CPP ignores INC Config option, but the bug
has been discovered in Inline::C: $o-{ILSM}{MAKEFILE}{INC} gets
erased each time validate() sub is called (sometimes it occurs
several times per script execution).
A simple script demonstrating the precise problem would be handy, just
to make sure that we (I) understand correctly. I'm not sure that the
suggested patch is really necessary ... though there's probably no
compelling reason to reject it.
Cheers,
Rob
I think the fault is in Inline::CPP, not Inline::C. If Inline::CPP generates
typemap data (if $typemap has non-zero length in Inline::CPP::write_typemap)
then Inline::CPP::validate is called with the generated TYPEMAP data passed,
but this calls Inline::C::validate, which sets $o-{ILSM}{MAKEFILE}{INC},
unless $o-UNTAINT is set.
A simple script which elicits the problem is as follows. The extra include
directory is useless, but it is also lost. Sorry, but the real case I was
working on is a lengthy mess at the moment and I don't know a simple case where
the extra include is actually needed.
Part of the issue is that when validating TYPEMAP, all the other options are
not passed to Inlince::C::validate. The initialization there sets INC and the
previously passed value is not appended because it is not passed, only the
TYPEMAP is passed.
#!C:/strawberry/perl/bin/perl.exe
#
use strict;
use warnings;
use Inline ('CPP' = 'DATA',
'INC' = '-IC:/',
);
print 9 + 16 = , add(9, 16), \n;
__END__
__CPP__
// change 7
int add(int x, int y) {
return x + y;
}
// Adding the following class causes Inline:CPP to generate
// typemap data which is validated. The validation of the
// typemap data causes the configuration of INC to be lost
// In this case, Inline::C::validate, which is called from
// Inline::CPP::validate, sets $o-{ILSM}{MAKEFILE}{INC}
// unless $o-UNTAINT is set.
class CRectangle {
int x, y;
public:
void set_values(int, int);
int area() { return(x*y); }
};
void CRectangle::set_values(int a, int b) {
x = a;
y = b;
}
[rt.cpan.org #11748] Inline::CPP config gets lost because of Inline::C bug
Sat Apr 20 04:43:46 2013: Request 11748 was acted upon.
Transaction: Correspondence added by iang
Queue: Inline
Subject: Inline::CPP config gets lost because of Inline::C bug
Broken in: (no value)
Severity: Important
Owner: Nobody
Requestors: nick_...@pisem.net
Status: open
Ticket URL: https://rt.cpan.org/Ticket/Display.html?id=11748
I have looked at this a little further and, while I don't see any evidence of a
bug in Inline::C, the bug in Inline::CPP (see Bug #84762) can be fixed by a
change to Inline::C.
An alternative to the change previously suggested is to change
Inline::C::validate
if (not $o-UNTAINT and not defined($o-{ILSM}{MAKEFILE}{INC})) {
require FindBin;
$o-{ILSM}{MAKEFILE}{INC} = -I\$FindBin::Bin\;
}
This has the very small advantage of not requiring FindBin unless it will be
used.
I don't understand what is happening to be confident this is the best way to
fix the bug in Inline::CPP or that it doesn't cause other problems, but it is
consistent with the other initializations in Inline::C::validate - only setting
INC to default value if it is not already set.
[rt.cpan.org #11748] Inline::CPP config gets lost because of Inline::C bug
Sat Apr 20 07:06:17 2013: Request 11748 was acted upon. Transaction: Correspondence added by SISYPHUS Queue: Inline Subject: Inline::CPP config gets lost because of Inline::C bug Broken in: (no value) Severity: Important Owner: Nobody Requestors: nick_...@pisem.net Status: open Ticket URL: https://rt.cpan.org/Ticket/Display.html?id=11748 On Sat Apr 20 04:43:46 2013, iang wrote: I have looked at this a little further and, while I don't see any evidence of a bug in Inline::C, the bug in Inline::CPP (see Bug #84762) can be fixed by a change to Inline::C. Thanks for the test case - and for digging around and providing ideas on how to fix this. Now that I have a demo to study, I can see that the '-IC:/' gets lost inside Inline::C::validate (which is called near the end of Inline::CPP::validate). This would suggest to me that it *is* a bug in Inline::C. I'll do something about this when I get the time to study more closely what's going on. (Should have some time for that within the next fortnight.) Thanks again, Ian. Cheers, Rob
