The dreaded regex patch

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 This is only a problem on native Windows, not on Cygwin;

Re: The dreaded regex patch

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

Re: The dreaded regex patch

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

RE: The dreaded regex patch

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

Re: The dreaded regex patch

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

Re: The dreaded regex patch [APPLIED]

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