regexp matches are sensitive to position in check items

[Jakob Hirsch]

Quoting Phil Mayers:

> Basically, this works in "hints":
> 
> DEFAULT NAS-Port-Id =~ "(.+):(.+)", NAS-Port !* ANY
>         NAS-Port = `%{expr:1000*%{1} + %{2}}`,
>         Fall-Through = Yes
> 
> ...but this does not:
> 
> DEFAULT NAS-Port !* ANY, NAS-Port-Id =~ "(.+):(.+)"
>         NAS-Port = `%{expr:1000*%{1} + %{2}}`,
>         Fall-Through = Yes
> 
> ...as %{1} and %{2} are undefined in the latter case. I would have 
> expected this to be the opposite case if anything. Is this expected?

I just stumbled over the same, but with huntgroups. Both use paircmp(), 
so they have the same problem: a positive "!*" (T_OP_CMP_FALSE) 
condition short-cuts the whole line, so the remaining comparisons are 
not done. In your case, the regex is not done then, so %{*} are not defined.

This is caused by an apparent bug in src/main/valuepair.c. Line 287 
should say "continue;" instead of "return 0;".

Oh, and to save some processor time, the same logic there (only inverted 
) could be used for the "=*" (T_OP_CMP_TRUE) operator.

I'll be happy to provide a patch, I just don't know if Alan will release 
any further 1.1.x version.

> In 2.0 I would use an "if" unlang, but this is on our (soon to be 
> upgraded) production servers.

Hope we can do this here soon, too.