On Fri, 23 Feb 2007, Bob Rossi wrote:
> > > > diff -ruN pcre-7.0/pcre_compile.c pcre-7.1-RC0/pcre_compile.c
> > > > --- pcre-7.0/pcre_compile.c 2006-12-19 04:31:35.000000000 -0500
> > > > +++ pcre-7.1-RC0/pcre_compile.c 2007-02-21 22:21:29.000000000 -0500
> > > > @@ -312,7 +312,7 @@
> > > > 0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00, /* - 71 40 */
> > > > 0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00, /* 72- | */
> > > > 0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00, /* & - 87 50 */
> > > > - 0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00, /* 88- ? */
> > > > + 0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00, /* 88- */
> > >
> > > Do you really want to change the above?
> >
> > Argh! Looks like my editor mangled a Latin-1 character. That'll definitely
> > have to go... we could convert it to UTF-8, but the safest thing would be
> > to change it to a \x## or \### character reference, so that the source file
> > is 7-bit clean.
The source should be 7-bit clean. It should just be the numerical value
95. Character 95 in EBCDIC is a logical "not" sign. I suspect the
creator of this table (who sent me the original patch) translated it
from EBCDIC to ISO-8859-1 and so the logical not turned into 0xAC, which
is what's in my source.
> > This output is from a pcregrep -L -r command, which gives a list of files
> > as output. The list, alas, is not sorted, and the test was failing for me
> > as I was getting a different file order than the reference. So I re-sorted
> > the list to proper lexical order ('8' < 'x') and added a sort(1) command to
> > RunGrepTest.in so that the output is always sorted.
>
> Does the test fail with pcre-7.0 as well? I wouldn't want to improve the
> test suite in this patch if it was failing before as well.
It does not fail on my box, but it *does* fail on some other boxes - I
already had this down as a bug that needed fixing. Without the fix the
output is dependent on the order in which files are processed when
pcregrep is scanning a directory. This depends on the file system, it
seems.
> Can't wait to see the next patch.
I can wait till next week... :-) [It's getting towards the end of Friday
on this side of the pond.]
Philip
--
Philip Hazel, University of Cambridge Computing Service.
