looking at the code, i appears that mt_match does not initialize pv_values pv when it stores matched values thus keeping possible existing values from previous calls. is that intended behavior? readme uses word "store".
-- juha
On 05/09/14 12:16, Juha Heinanen wrote:
looking at the code, i appears that mt_match does not initialize pv_values pv when it stores matched values thus keeping possible existing values from previous calls. is that intended behavior? readme uses word "store".
Don't remember by hard exactly what to refer to, but if it is about result pv, some types cannot be initialized (e.g., avp/xavp).
If you have something particular in mind, make a patch and we can see if there is any side effect. Otherwise, I would expect to use the result pv only if the match is successful, therefore not needing/expecting the previous values.
Cheers, Daniel
Daniel-Constantin Mierla writes:
On 05/09/14 12:16, Juha Heinanen wrote:
looking at the code, i appears that mt_match does not initialize pv_values pv when it stores matched values thus keeping possible existing values from previous calls. is that intended behavior? readme uses word "store".
Don't remember by hard exactly what to refer to, but if it is about result pv, some types cannot be initialized (e.g., avp/xavp).
If you have something particular in mind, make a patch and we can see if there is any side effect. Otherwise, I would expect to use the result pv only if the match is successful, therefore not needing/expecting the previous values.
i would just like to call destroy_avps, before starting to add matching values to the avp. otherwise the avp may have old values from previous mt_match call.
-- juha
On 05/09/14 14:57, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
On 05/09/14 12:16, Juha Heinanen wrote:
looking at the code, i appears that mt_match does not initialize pv_values pv when it stores matched values thus keeping possible existing values from previous calls. is that intended behavior? readme uses word "store".
Don't remember by hard exactly what to refer to, but if it is about result pv, some types cannot be initialized (e.g., avp/xavp). If you have something particular in mind, make a patch and we can see if there is any side effect. Otherwise, I would expect to use the result pv only if the match is successful, therefore not needing/expecting the previous values.
i would just like to call destroy_avps, before starting to add matching values to the avp. otherwise the avp may have old values from previous mt_match call.
IIRC, there can be other types of variables used to store the result, thus I am not sure that is easily possible for all cases.
If you get a patch you think is solving it, then I would not mind having it if there are no side effects.
Cheers, Daniel
Daniel-Constantin Mierla writes:
IIRC, there can be other types of variables used to store the result, thus I am not sure that is easily possible for all cases.
doesn't this values_param check mean that the param must be avp?
if (pv_parse_spec(&values_param, &pv_values) <0 || pv_values.type != PVT_AVP) { LM_ERR("cannot parse values avp\n"); return -1; }
-- juha
On 05/09/14 15:07, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
IIRC, there can be other types of variables used to store the result, thus I am not sure that is easily possible for all cases.
doesn't this values_param check mean that the param must be avp?
if (pv_parse_spec(&values_param, &pv_values) <0 || pv_values.type != PVT_AVP) { LM_ERR("cannot parse values avp\n"); return -1; }
I had in mind pv_value (which I added), but I see there is also pv_values (most probably added by you?!?), which I don't remember using it for my configs. Looks like it is ok to add that given the restrictions on pv type. If nobody else has concerns on side effects, it is fine for me to call destroy avps.
Cheers, Daniel
-
Daniel-Constantin Mierla -
Juha Heinanen