Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!usc!elroy.jpl.nasa.gov!jpl-devvax!lwall
From: lwall@jpl-devvax.JPL.NASA.GOV (Larry Wall)
Newsgroups: comp.lang.perl
Subject: Re: regexp and slice bugs
Message-ID: <8547@jpl-devvax.JPL.NASA.GOV>
Date: 29 Jun 90 20:06:47 GMT
References: <8483@ubc-cs.UUCP>
Reply-To: lwall@jpl-devvax.JPL.NASA.GOV (Larry Wall)
Organization: Jet Propulsion Laboratory, Pasadena, CA
Lines: 42

In article <8483@ubc-cs.UUCP> phillips@cs.ubc.ca (George Phillips) writes:
: Under perl 3.0, patchlevel 18, the following script gives a wrong answer:
: 
: $block = "a\nd";
: print $block =~ /^d/;		print "\n";
: print $block =~ /^\144/;	print "\n";
: 
: The second regexp matches.  It seems like the bug is in scanconst() since
: it doesn't understand octal escapes and therefore doesn't give the right
: answer to scanpat().  On the other hand, scanconst() may not be to blame
: but its minor failure lets a bug crawl out of somewhere else.

From the manual:

     By default, the ^ character is only guaranteed to  match  at
     the beginning of the string, the $ character only at the end
     (or before the newline at the end)  and  perl  does  certain
     optimizations  with  the assumption that the string contains
     only one line.  The behavior of ^ and $ on embedded newlines
     will  be  inconsistent.   You  may, however, wish to treat a
     string as a multi-line buffer, such that the  ^  will  match
     after any newline within the string, and $ will match before
     any newline.  At the cost of a little more overhead, you can
     do this by setting the variable $* to 1.  Setting it back to
     0 makes perl revert to its old behavior.

: The other bug can come up in many ways, but you can reproduce it 
: (and a core dump) with:
: 
: @out[0] + 1;
: 
: I haven't found a fix here either, but it seems that the array slice 
: routine ends up returning a NULL pointer for the single element slice
: ('cause that's what afetch() returned).  Add blindly converts the top 
: two stack elements to numbers and crashes when it hits the NULL.  Maybe
: do_slice() shouldn't put Nullstr on the stack or maybe add (and others)
: should be more careful.  Who knows?  Larry!  Guide us!

I suppose I really should decide one way or the other.  It's one of
those stupid things I could argue either way.

Larry