> On Fri, Jan 05, 2001 at 07:15:01AM -0600, Jarkko Hietaniemi wrote: > > On Fri, Jan 05, 2001 at 01:53:47PM +0100, Andreas J. Koenig wrote: > > > >>>>> On Fri, 5 Jan 2001 12:28:52 +0100 , "Roca, Ignasi" > <ignasi.roca@fujitsu.siemens.es> said: > > > > > > > Strings with \x{..} in the middle are corrupted, test 22 of > op/bop.t fails. > > > > This happens in the paragrah that recodes what is accumulated > before first > > > > \x{...}. > > > > > > FWIW, op/bop.t doesn't fail for me with patches upto 8327 > neither > > > before nor after your patch. Maybe you can think of another test > that > > > > Maybe something to do with ASCIIish assumptions (didn't look at > the > > patch yet, so I'm guessing)? Mr. Ignasi hails from EBCDIC lands. > > Yes, it seems that the code once again assumed ASCII encoding, the > raw > & 0x80 tells us that. I actually already had changed that to be > abstracted behind a macro, UTF8_IS_CONTINUED(). Next we'll need to > define these macros in EBCDIC correctly (mapping to ASCII and back). > Simon Cozens already had some patches to this effect a few weeks > back, > I'll go dig. > > Yes I'm working on an EBCDIC environment. > In any case function uv_to_utf8 adds a NULL character at the end of the > destination buffer and as it is handling the string backwards, last > character will be overwritten. > So I thing that my patch should be applied. > I'm asking in which case can, in ASCII environment, appear these bug. Can you try without the patch following: print "ok \xFF\x{FF}\n" & "ok 22\n"; and add it to the op/bop.t script ? > > > > would fail for me? > > > > > > BTW, the patch arrived here line-wrapped. I fixed that manually > and > > > applied with -l. Maybe you should resubmit as an attachment and > > > include your perl -V. > > -- > $jhi++; # http://www.iki.fi/jhi/ > # There is this special biologist word we use for 'stable'. > # It is 'dead'. -- Jack Cohen