Re: Problem with setting substring match variables (%{1} etc.)

9 Aug 2007

      Hi,

Alan DeKok wrote:
...
Enrik Berkhan wrote:
...
Is this expected behaviour? If not, how can this be fixed? Just leave
out the 'break' in the for loop? (Code from valuepair.c)
Likely, yes.
If that works, please say so, and I'll commit a patch.  I'm a little
overloaded right now, and can't look at it myself.
For testing, I've changed the inner 'no match or no subexpression match'
condition of the four for-loops that are currently used to update
%{0}... in the following way:

old:
...
if (r) {
   free(r);
   continue;
 }
 break;
new:
...
if (r) {
   free(r);
 }
 continue;
This seems to work, variables are unset if they have an old value and no
new value (no match at all or empty) or they are set/updated if they
have a new value (match implied).

I've only tested it using unlang:
...
if ("%{User-Name}" =~ /^(a)(.)(.)/) {
    update reply {
      Reply-Message := "first match: 0:%{0} 1:%{1} 2:%{2} 3:%{3} "
    }
  }
  else {
    update reply {
      Reply-Message := "no match on first regex"
    }
  }
  if ("%{User-Name}" =~ /^(a|b)?(.)/) {
    update reply {
      # += segfaults?!
      #Reply-Message += "second match: 0:%{0} 1:%{1} 2:%{2} 3:%{3} "
      Reply-Message := "%{reply:Reply-Message}; second match: 0:%{0} 1:%{1} 2:%{2} 3:%{3} "
    }
  }
  else {
    update reply {
      #Reply-Message += "no match on second regex"
      Reply-Message := "%{reply:Reply-Message}; no match on second regex"
    }
  }
The for-loops to update %{0}... are currently explicitly found in

- src/main/evaluate.c
- src/main/valuepair.c
- src/modules/rlm_attr_rewrite/rlm_attr_rewrite.c (slight variation:
doesn't touch the variables on no match)
- src/modules/rlm_policy/evaluate.c

Shouldn't this be moved to a single place like a function in
src/main/util.c or main/xlat.c called xlat_update_regex or so?

Further, I've noticed that in all places where regex-no-match operators
are implemented but in src/modules/rlm_policy/evalute.c, the
subexpressions are evaluated but never used later. May this could be
fixed, too.

Of course I could provide patches for all of this or parts thereof if
it's the right direction. Just tell me what you'd prefer.

Now I'm gonna try to find out why the += segfaults in the above unlang
example ...

Enrik