regexp matches are sensitive to position in check items

[Phil Mayers]

Jakob Hirsch wrote:
> 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.

Ah, yes of course.

> 
> 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.

Does the same bug not exist in 2.0?

> 
>> 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.
> 
> -
> List info/subscribe/unsubscribe? See 
> http://www.freeradius.org/list/users.html