I'm concerned as well given that the types of problems described could cause real difficulty with working with PDL data from the perl level since it seems to cause spooky action at a distance that is different than all previous expectations.
The use case that comes to mind is doing large data IO, say a stream of bytes, and then "casting" that into the desired piddle "in place" without a copy being forced. I haven't looked at 5.20.1 docs yet but are there some guidelines for how to avoid these types of problems that will work in a back-compatible fashion? --Chris On Fri, Sep 19, 2014 at 5:55 AM, Niels Larsen <[email protected]> wrote: > 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 _______________________________________________ Perldl mailing list [email protected] http://mailman.jach.hawaii.edu/mailman/listinfo/perldl
