Craig A. Berry <[EMAIL PROTECTED]> writes: >At 2:03 PM +0100 5/18/02, Nick Ing-Simmons wrote: >>Nick Ing-Simmons <[EMAIL PROTECTED]> writes: >>>Dan Kogai <[EMAIL PROTECTED]> writes: >>>>> ok 26 - >:encoding(euc-kr) by lines >>>>> euc-kr "\xAD" does not map to Unicode at [-.ext.encode.t]perlio.t line >>>>> 106, <$fh> line 230. >>>>> not ok 27 - <:encoding(euc-kr) >>>>> # Failed test ([-.ext.encode.t]perlio.t at line 109) >>>>> euc-kr "\xAD" does not map to Unicode at [-.ext.encode.t]perlio.t line >>>>> 117, <$fh> line 230. >>>>> not ok 28 - <:encoding(euc-kr) by lines >>>>> # Failed test ([-.ext.encode.t]perlio.t at line 123) >>>>> # Looks like you failed 2 tests of 28. >>>>> %SYSTEM-F-ABORT, abort >>>>> $ >>>> >> >>I smell PerlIO::encoding rather than Encode::XS but this is really, > > >>My current guess is that VMS's version of perl's MOVE() macro >>which is used very indirectly to rearrange data in :encoding's buffer >>is buggy for overlapping moves - or there is an off-by-one error >>somewhere in encoding.xs (had another stare at that can't see it) >>or Encode.xs > >I'm afraid I can't fine a MOVE() macro anywhere. Are we talking >about HAS_MEMMOVE? We do define that and the C library docs claim >memmove is identical to memcpy and that both can handle overlapping >memory sections.
Sorry my mistake I meant Move() - but if your memcpy and memmove() both do overlapping then that is probably not the issue. > >>Can someone on VMS run the test in the VMS equivalent of the following >> >>cd bleadperl/t >>PERL_CORE=1 ./perl -I../lib ../ext/Encode/t/perlio.t 1 >> >>The trailing 1 sets debug which means a lot of .sio.N and .pio.N >>files get left. > >Running with debugging on results in pages and pages of unmappable >character warnings (presumably in the dump2file routine). That is odd I would have expected linux to do that as well if it was going to do it on VMS - it doesn't. >Then it >gobbles CPU and memory until it eventually runs out of the latter: > >shiftjis "\x86" does not map to Unicode at [-.ext.encode.t]perlio.t line 117, <$fh> >line 223. >shiftjis "\x81" does not map to Unicode at [-.ext.encode.t]perlio.t line 117, <$fh> >line 223. >shiftjis "\xA0" does not map to Unicode at [-.ext.encode.t]perlio.t line 117, <$fh> >line 223. >shiftjis "\x87" does not map to Unicode at [-.ext.encode.t]perlio.t line 117, <$fh> >line 223. >shiftjis "\xA0" does not map to Unicode at [-.ext.encode.t]perlio.t line 117, <$fh> >line 223. >shiftjis "\xA0" does not map to Unicode at [-.ext.encode.t]perlio.t line 117, <$fh> >line 223. >shiftjis "\x87" does not map to Unicode at [-.ext.encode.t]perlio.t line 117, <$fh> >line 223. >shiftjis "\x86" does not map to Unicode at [-.ext.encode.t]perlio.t line 117, <$fh> >line 223. >shiftjis "\x99" does not map to Unicode at [-.ext.encode.t]perlio.t line 117, <$fh> >line 223. >not ok 12 - <:encoding(shiftjis) by lines ># Failed test ([-.ext.encode.t]perlio.t at line 123) >ok 13 - >:encoding(7bit-jis) >ok 14 - >:encoding(7bit-jis) by lines >ok 15 - <:encoding(7bit-jis) >Out of memory! ># Looks like you planned 28 tests but only ran 15. >%SYSTEM-F-ABORT, abort > >So whatever is bolloxed up is clearly not just a problem for euc-kr. >It appears that dump2file works ok when autoflush is on, but has >major problems when it's turned off. Which is very peculiar. dump2file does open, binmode, one print and close. As there is only one print, and that is immediately followed by a close autoflush should make little difference. What if anything does binmode() do on VMS? -- Nick Ing-Simmons http://www.ni-s.u-net.com/
