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
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]
or
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 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 for
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