Re: bug in gawk 3.1.0 regex code

[laura fairhead]

On Fri, 10 May 2002 02:30:07 GMT, address@hidden (laura fairhead) wrote:

>Hi,
>       
>I believe I've just found a bug in gawk3.1.0 implementation of
>extended regular expressions. It seems to be down to the alternation
>operator; when using an end anchor '$' as a subexpression in an
>alternation and the entire matched RE is a nul-string it fails
>to match the end of string, for example;
>
>gsub(/$|2/,"x")
>print
>
>input           = 12345
>expected output = 1x345x
>actual output   = 1x345
>
>The start anchor '^' always works as expected;
>
>gsub(/^|2/,"x")
>print
>
>input           = 12345
>expected output = x1x345
>actual output   = x1x345
>
>This was with POSIX compliance enabled althought that doesn't
>effect the result.
>

I think I've just found where this bug is coming from, it's not
just a problem with the end anchor it seems to be a class of bugs
due to successive matching of a non-nul-string stopping the next
nul-string from matching. This is being investigated at the moment
on comp.lang.awk in the following thread;

From: address@hidden (laura fairhead)
Newsgroups: comp.lang.awk
Subject: bug in gawk3.1.0 regex code
Date: Wed, 08 May 2002 23:31:40 GMT
Message-ID: <address@hidden>

The example I posted there is;

input          =12345 626
operation      =gsub(/3|\</,"x")
expected output=x12x45 x626
output         =x12x45 626

input          =12345 1245 1245
operation      =gsub(/3|\</,"x")
expected output=x12x45 x1245 x1245
output         =x12x45 1245 x1245


byefornow

-- 
laura fairhead  # address@hidden  http://lf.8k.com
                # if you are bored crack my sig.
1F8B0808CABB793C0000666667002D8E410E83300C04EF91F2877D00CA138A7A
EAA98F30C494480157B623C4EF1B508FDED1CEFA9152A23DE35D661593C5318E
630C313CD701BE92E390563326EE17A3CA818F5266E4C2461547F1F5267659CA
8EE2092F76C329ED02CA430C5373CC62FF94BAC6210B36D9F9BC4AB53378D978
80F2978A1A6E5D6F5133B67B6113178DC1059526698AFE5C17A5187E7D930492