Rob, I found the discussion I think you refer to,
http://grokbase.com/t/perl/perl5-porters/1325q5s51n/perl-116569-re-5-17-7-breaks-rules-of-assignment I and many others have code like yours, where a Perl string is passed with SV* to C as an array, which is read and modified in C. I let Perl do all memory management. I can change my own Inline/XS but customers with existing code who update their Perl (or the sysop does it rather) will get the breakage and I get the blame. This isn't PDL stuff, but I just don't agree with the response you got. At least they should support an environment variable that turns COW off, I think. I will try again on the P5P list .. Niels L On Fri, 2014-09-19 at 12:14 +1000, [email protected] wrote: > -----Original Message----- > From: Niels Larsen > Sent: Friday, September 19, 2014 12:05 AM > > > I have not yet reported the problem and found no complaints with > > Google, so maybe I missed something. Or have the Perl people > > forgotten about Inline .. ? > > Inline will be subject to the same behaviour as XS. > > Only time I’ve been bitten by COW was doing something like this: > > ######################################## > use strict; > use warnings; > > use Inline C => Config => > BUILD_NOISY => 1, > USING => 'ParseRegExp'; > > use Inline C => <<'EOC'; > > void change_char(char * in) { > sprintf(in, "%d", -123); > } > > EOC > > my $orig = 'XOXO'; > my $copy = $orig; > > print "$orig $copy\n"; > > change_char($orig); > > print "$orig $copy\n"; > ######################################## > > On 5.18 and earlier, this script outputs: > > XOXO XOXO > -123 XOXO > > But with 5.20, when you call change_char() to alter $orig, it also alters > $copy - ie the script outputs: > > XOXO XOXO > -123 -123 > > According to p5p, this is a misuse of the char* typemapping, which was not > intended to accommodate this type of writing, though the following (which > avoids the char* typemapping) does exactly the same thing: > > void change_char(SV * in) { > sprintf(SvPV_nolen(in), "%d", -123); > } > > (No doubt this is also misuse, hidden under another cloak.) > > I think there are API calls one can make to avoid the problem, but I ended > up just rewriting my XS code such that whenever an XSub writes to a buffer, > it writes to a buffer that was created in XSpace (not a buffer that was > passed to it from Perl-space). > > I think you'll find that any XS/Inline problems you're having with COW will > be (in the view of p5p, at least) because the XS code needs to be > rewritten - not because of some problem with COW itself. > But without seeing an actual demo of your problem, I'm only speculating. > > I don't think there should *ever* be a need to make amendments to a C > library - though there may well be situations where the (XS) code that > accesses that library needs to be changed. > > Cheers, > Rob > > _______________________________________________ Perldl mailing list [email protected] http://mailman.jach.hawaii.edu/mailman/listinfo/perldl
