[Serusers] [Serdev] [Tracker] Reopened: (SER-263) Using @select=~ "regexp" causes segmentation fault

[samuel]

IMHO,

I wouldn't "equalize" non-existent parameter with empty string. There are
header parameters (maddr,rport,isfocus) which may not have value and someone
(who knows?) might need to check for them. I would just not forbid this
option from the config file...

I would just use the @ and !@ uses for detecting presence or absence of
attributes and letting the == to check for the value once you know it
exists. It "complicates" a little bit config file but makes it clearer and I
think easier to debug.

So, for me it's fine changing example config files and documenting it.

my 0.02,
Samuel

2007/6/8, Michal Matyska <michal at iptel.org>:
>
> Samuel,
>
> yes it is related to. The resolution of SER-263 was wrong and every test
> like   if (@select=="")  has returned false, even the return value of
> the select was empty string.
>
> But, there is another problem I see in the config (including the example
> script)...
>
> There is difference between the (@select) test and (@select!="") one.
> The latter returns false, if the select framework returns N/A value
> (e.g. non present header/parameter).
>
> Intended behaviour was: @X is @route[1].params.lr in this example
> (as the tag must have value if present rfc3261 19.3)
>
> lr parameter    test    result
> not present     @X      false
>                 !@X     true
>                 @X==""  FALSE*
>                 @X!=""  FALSE*
>
>
> lr              @X      true
>                 !@X     false
>                 @X==""  true
>                 @X!=""  false
>
> lr=123          @X      true
>                 !@X     false
>                 @X==""  false
>                 @X!=""  true
>
>
> As I see the from the example ser.cfg, the tests are done in the
> (@to.tag=="") way, which won't work if the to.tag would return either
> N/A or the tag value. But it seems it returns the empty string even if
> not present, because it was previously working.
>
> So I ask the community (especially TB potential members) do we want to
> take care about the select N/A value differently, or shall we make it
> equal to empty string?
>
> Note, that if the answer is yes, it will be very hard to differentiate
> between parameter not present and parameter without value - well the lr
> parameter is handled internally, but what others?
>
> If the anwser is no, keep special N/A value handling, the select must be
> reviewed together with the ser.cfg, because (@to.tag=="") will be false
> for every tag (because it must have value).
>
> Michal
>
> On Čt, 2007-06-07 at 13:56 +0200, samuel wrote:
> > Michal,
> >
> > I've just post a question to users' list about not properly detecting
> > @to.tag=="".
> >
> > Is this bug related to it??
> >
> > Thanks,
> > Samuel.
> >
> > 2007/6/7, Michal Matyska (JIRA) < tracker at iptel.org>:
> >              [ http://tracker.iptel.org/browse/SER-263?page=all ]
> >
> >         Michal Matyska reopened SER-263:
> >         --------------------------------
> >
> >
> >         The way it is now resolved is wrong. If the select returns
> >         empty string the script test if (@select=="")  is false.
> >
> >         > Using @select=~ "regexp" causes segmentation fault
> >         > --------------------------------------------------
> >         >
> >         >                 Key: SER-263
> >         >                 URL: http://tracker.iptel.org/browse/SER-263
> >         >             Project: SER
> >         >          Issue Type: Bug
> >         >          Components: core, Selects
> >         >    Affects Versions: 2.0, Ipteldorf
> >         >         Environment: CVS head
> >         >            Reporter: Michal Matyska
> >         >         Assigned To: Michal Matyska
> >         >            Priority: Minor
> >         >             Fix For: 2.0, Ipteldorf
> >         >
> >         >
> >         > If the result of the select is empty string or it is
> >         STR_STATIC_INIT ( e.g. @uri.type) the prepatation of left
> >         operand (putting \0 behind the string) causes segmentation
> >         fault .
> >         > Program received signal SIGSEGV, Segmentation fault.
> >         > comp_str (op=11, left=0xbfad27a4, rtype=5, r=0x81932b0,
> >         msg=0x81a1034) at route.c:668
> >         > 668                             left->s[left->len]='\0';
> >
> >         --
> >         This message is automatically generated by JIRA.
> >         -
> >         If you think it was sent incorrectly contact one of the
> >         administrators:
> >         http://tracker.iptel.org/secure/Administrators.jspa
> >         -
> >         For more information on JIRA, see:
> >         http://www.atlassian.com/software/jira
> >
> >
> >         _______________________________________________
> >         Serdev mailing list
> >         Serdev at lists.iptel.org
> >         http://lists.iptel.org/mailman/listinfo/serdev
> >
> > _______________________________________________
> > Serdev mailing list
> > Serdev at lists.iptel.org
> > http://lists.iptel.org/mailman/listinfo/serdev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20070608/1af0a516/attachment.htm>