At 03:16 AM 1/9/2002 -0800, Brent Dax wrote:
>Okay, here it is. Attached is the regular expression patch. It
>currently segfaults on Windows because of a combination of two factors:
>
> 1) There are some bounds-checking issues in key.c
> 2) Windows's malloc() isn't as robust as Unix's
I've ap
On Wed, Jan 09, 2002 at 12:44:45PM -0800, Brent Dax wrote:
> Steve Fink:
> # On Wed, Jan 09, 2002 at 03:16:40AM -0800, Brent Dax wrote:
> #
> # Also, why specific opcodes for \w etc.? I would think you'd do those
> # as constants. (Constant bitmaps for 8-bit, or constant
> # MultiLevelFunkyThings
Steve Fink:
# On Wed, Jan 09, 2002 at 03:16:40AM -0800, Brent Dax wrote:
# > Okay, here it is. Attached is the regular expression patch. It
#
# Is rx_advance necessary? What's the difference between
#
# /R/
#
# and
#
# /^(.*?R)/
#
# if you count the parens $& $1 $2 ... instead of $1 $2 $3 ..
On Wed, Jan 09, 2002 at 03:16:40AM -0800, Brent Dax wrote:
> Okay, here it is. Attached is the regular expression patch. It
Is rx_advance necessary? What's the difference between
/R/
and
/^(.*?R)/
if you count the parens $& $1 $2 ... instead of $1 $2 $3 ...?
Speed, I guess?
(Okay, I r
At 01:49 PM 1/9/2002 +, Nicholas Clark wrote:
>On Wed, Jan 09, 2002 at 03:16:40AM -0800, Brent Dax wrote:
> > 2) Windows's malloc() isn't as robust as Unix's
>
>In what way? Windows malloc() is getting upset with buggy allocations that
>a Unix malloc() will typically stomach? [ie perl6 bugs]
On Wed, Jan 09, 2002 at 03:16:40AM -0800, Brent Dax wrote:
> 2) Windows's malloc() isn't as robust as Unix's
In what way? Windows malloc() is getting upset with buggy allocations that
a Unix malloc() will typically stomach? [ie perl6 bugs]
or Windows malloc() is getting upset with legal but awkw
