Front page | perl.perl5.porters |
Postings from March 2007
From: Alexey Tourbin [mailto:at@altlinux.ru]
> On Tue, Feb 27, 2007 at 09:40:40PM +0100, demerphq wrote:
> > On 2/27/07, Alexey Tourbin <at@altlinux.ru> wrote:
> > >As ninstr() seems to have undocumented semantics, I guess its usage
> > >should be replaced wherever possible. Here is where it is actually
> > >(was) used. The list is not exhaustive.
> > >
> > [...]
> > >perl-devel /usr/lib/perl5/i386-linux/auto/re/re.so U
> Perl_ninstr
> > >perl-devel /usr/lib/perl5/i386-linux/auto/re/re.so U
> > >Perl_rninstr
> > >at@mash ~/.qa-robot/bad_elf_symbols $
> > >
> > >Look, I've got some binary compatibility analysis framework.
> >
> > line 2048 of regexec.c in Perl_regexec_flags:
> >
> > last = rninstr(s, strend, little, little + len);
> >
> > line 2337 of regcomp.c in S_join_exact:
> >
> > for (s = s0 + 2;
> > s < s2 && (t = ninstr(s, s1, t0, t1));
> > s = t + 4) {
> >
> > Oh you have to love code like that dont you? Ask me what
> > s1,t0,t1,s0,s2 later, I have no idea right now. :-)
>
> Doh. GNU glibc has memmem(3) with more usual semantics, like strstr(3).
> One problem that makes ninstr() unusual is that its `end' arguments
> actually point to the last character, not after the last character (like
> iterators in the thing called C+plus). So... maybe it would be wise to
> implement memmem() inside perl core, unless it is already available, and
> reimplement ninstr() in terms of memmem() for backward compatibility.
Alexey, I see you have raised tickets (25205 and 25206) against the CPAN
versions of Filter::Util::Call and Compress::Zlib suggesting they use memchr
instead of ninstr.
Compress::Zlib 1.x has been put out to pasture. The active version is now
2.003. It doesn't use xsub to implement the readline functionality anymore,
so the ninstr issue doesn't arise.
The story with Filter::Util::Call is a bit more complex - core patch 26509
is included in the CPAN version of Filter::Util::Call and will be compatible
with the ninstr change in 5.8.9. But a couple of the other filters in the
Filters distribution fail. They all trip over the same ninstr issue. So I'm
going to have to spin a new release for them.
So that raises the question of whether to use ninstr or memchr? Unless there
is a real problem in the ninstr implementation, I'm inclined to stay with
it.
If anyone knows a reason why I shouldn't, please speak up.
Paul
Thread Previous
|
Thread Next