Skip Menu |

Preferred bug tracker

Please visit the preferred bug tracker to report your issue.

This queue is for tickets about the Inline CPAN distribution.

Report information
The Basics
Id: 11748
Status: resolved
Priority: 0/
Queue: Inline

People
Owner: Nobody in particular
Requestors: nick_msu [...] pisem.net
Cc:
AdminCc:

Bug Information
Severity: Important
Broken in: (no value)
Fixed in: (no value)



Subject: Inline::CPP config gets lost because of Inline::C bug
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). Workaround: $o->{ILSM}{MAKEFILE}{INC} = "-I$FindBin::Bin"; should be replaced with: $o->{ILSM}{MAKEFILE}{INC} = "-I$FindBin::Bin" if not defined $o->{ILSM}{MAKEFILE}{INC}; The same action is done with other Config options by default, so it's strange why INC is being ignored.

Message body is not shown because it is too large.

On Fri Mar 04 06:12:48 2005, guest wrote: Show quoted text
> 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
From: Ian.Goodacre [...] xtra.co.nz
On Mon Jun 29 19:24:59 2009, SISYPHUS wrote: Show quoted text
> 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; }
From: Ian.Goodacre [...] xtra.co.nz
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.
On Sat Apr 20 04:43:46 2013, iang wrote: Show quoted text
> 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
On Sat Apr 20 02:53:07 2013, iang wrote: Show quoted text
> I think the fault is in Inline::CPP, not Inline::C.
Yes, I now think that *is* right. Show quoted text
> 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] Show quoted text
> 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
Marking as resolved. Fixed in Inline-0.53 (which was released to CPAN on 30th April 2013). Cheers, Rob