Front page | perl.perl5.porters |
Postings from January 2001
> 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