stan@sdba.UUCP (Stan Brown) (06/20/88)
I have recently seen a couple of patches to Perl 2.0 & saw a message from larry wall to the effect that it was ready to post. But I have not seen it posted yet. My question is, did I miss it? If so does anyone know how I can get it without internet access ? stan -- Stan Brown S. D. Brown & Associates 404-292-9497 (uunet gatech)!sdba!stan "vi forever"
lwall@devvax.JPL.NASA.GOV (Larry Wall) (06/29/88)
In article <275@sdba.UUCP> stan@sdba.UUCP (Stan Brown) writes:
:
: I have recently seen a couple of patches to Perl 2.0 & saw a
: message from larry wall to the effect that it was ready to
: post. But I have not seen it posted yet. My question is, did
: I miss it? If so does anyone know how I can get it without
: internet access ?
That's odd--I haven't posted any patches yet, though I have one ready to go.
Perl 2.0 has been in the comp.sources.unix queue for several weeks (I hope--
I didn't ask for a confirmation when I mailed it) and should come out any
moment now. It has been available for FTP since June 5. For those with
Internet access, if you can't find jpl-devvax.jpl.nasa.gov, try 128.149.8.43.
Larry Wall
lwall@jpl-devvax.jpl.nasa.govmkp@luna.UUCP (Michael Peterson) (06/30/88)
UNIXPC users be forewarned: Perl 2.0 (patchlevel 0) is broken on the UNIXPC under 3.51. It 'makes' without problems, but dies immediately with a memory fault down in the regex routines when attempting a 'make test.' Building perl with '#define ALIGN' or '#undef ALIGN' in regexp.c doesn't help, nor does using (or not using) the provided malloc.c. Haven't had a chance to look at the problem beyond that. -- Michael K. Peterson mkp@scgvaxd.hac.com Space & Communications Group mkp%scgvaxd.hac.com@oberon.usc.edu Hughes Aircraft Company 213 416-0323
hokey@plus5.UUCP (Hokey) (07/03/88)
It happens on our 68000 SysVr2.2 box, also. The problem seems to be around line 810 in regexp.c. While parsing the sharpbang regexp and determining the length of the compiled form, regcomp calls regpiece which calls regatom. The line in question is: *OPERAND(ret) = len; For reasons as yet unclear to me, this causes the value saved in regcode to be altered, which causes regc() to try to emit code instead of counting the byte. Since regcode is pointing to garbage, Bad Things happen. Perhaps I'll have more time to look at this today. -- Hokey