Nail down this bug?

[JJoe]

(Oct. 16, 2010 05:54 PM)sidki3003 Wrote:  It's apparently only about the .ptron file, the lists don't seem to be affected.

Quote:Any list call after a "negate string positional variable mess" seems to initialize all positional variables.

I was wrong. Something else in the web page filters was 'fixing' things.

TEST 1

Add: (^z)\0nevermatch(^)|$TST(\0=*) to Bypass List.txt.
Load: Google
Result: Web Page incorrectly bypassed.
Remove: Bypass entry



TEST 2

Add following filters

Code:

[Patterns]
Name = "A -- correct: $TST(\0=*) does not match"
Active = TRUE
Limit = 256
Match = "$TST(\0=*)"
Replace = "\k"

Name = "E --  use list to create problem"
Active = TRUE
Limit = 256
Match = "$LST(Bypass)"

Name = "Es --  use list to create problem"
Active = TRUE
Limit = 256
Match = "$LST(Bypass-List)"

Add: (^z)\0nevermatch(^) to Bypass List.txt.
Load: Google
Result: Web Page incorrectly 'killed'.



TEST 3

Enable: Filter A
Disable: Filter E and Filter Es
Add: (^z)\0nevermatch(^) to Bypass List.txt.
Load: Google
Result: Web Page loads as expected.

This test 3 shows that the \0 problem (created in the Bypass list) was 'fixed' by the Proxomitron before the Web Page Filter A tested the variable.

Remove: Bypass entry and filters
Note: Filter E is for Scott's set. Filter Es is for sidki's set.

Edit:

(Oct. 16, 2010 09:21 AM)whenever Wrote:  

(Oct. 16, 2010 04:48 AM)JJoe Wrote:  However, after filter "D" fails, filter "A" finds "$TST(\0=*)" to be true and matches.

Well, finally a serious bug found: a positional var lives between different filters.

Sidki mentioned another quirk about positional var before, which seems related: http://prxbx.com/forums/showthread.php?t...2#pid11062

Sidki also found this one. I'm just trying to document it and keep things moving.