[SR-Users] Re: Clarification of 'return false' behaviour
Hello,
the sip3.txt contains just a SIP message, nothing really special about it.
Cheers,
Henning
From: Patrick Wakano
Sent: Mittwoch, 3. Mai 2023 08:02
To: mico...@gmail.com
Cc: Kamailio (SER) - Users Mailing List
Subject: [SR-Users] Re: Clarification of 'return false' behaviour
Thanks Henning and Daniel for taking the time to check this out!
I will double check my env but anyway will review my script and follow Daniel's
recommendations!
Hennig, would you be able to disclose the contents of your /root/sip3.txt file?
It really got my interest in this nc usage!
Appreciate your replies!
Kind regards,
Patrick
On Tue, 2 May 2023 at 18:10, Daniel-Constantin Mierla
mailto:mico...@gmail.com>> wrote:
Hello,
indeed, it is somehow confusing, because in terms of evaluating the return code
in logical expression, 'false' means the return code was negative and 'true'
means it was positve.
Then the core keywords 'true' and 'false' are just aliases to 1 and 0 for use
with core parameters, but their meaning is not related to logical evaluation of
function's return code.
Someone decided like 20 years ago to have this kind of logical evaluation and
it continued to be like that till now.
There was a regression at some point when return 0 was no longer exiting, being
fixed at some point. One may notice the behaviour change if run same config
before and after.
In general is not good to just return the value from execution of a function,
but evaluate to true or false and return explicitly own values. Instead of
return x()
do:
if(x()) {
return 1;
} else {
return -1;
}
Cheers,
Daniel
On 01.05.23 01:10, Patrick Wakano wrote:
Thanks very much for the clarification Daniel! Appreciate it!
However it does seem that some modules have inconsistencies with return values
now. So, for instance, the is_ip_rfc918() says it will return true or false
(https://kamailio.org/docs/modules/5.6.x/modules/ipops.html#ipops.f.is_ip_rfc1918
- most functions of this module return true or false) and then when used
directly with return, it terminates execution. Based on your explanation, it
shouldn't return true or false, but likely -1 or 1, which would never be
considered 'return 0'
Also, the below code works in version 5.4, but terminates execution in version
5.6, so are you aware of changes in this behaviour in version 5.5 or 5.6
(before the 5.7 changes you mentioned)?
route[is_src_private]
{
return is_ip_rfc1918("$si");
}
request_route
{
...
if (route(is_src_private)) {
xlog("L_NOTICE", "SRC private\n");
} else {
xlog("L_NOTICE", "SRC public\n");
}
...
}
Best regards!
Patrick
On Fri, 28 Apr 2023 at 16:29, Daniel-Constantin Mierla
mailto:mico...@gmail.com>> wrote:
Hello,
false is 0 and it was actually designed for setting global parameters, not for
use as comparison with functions return code or as parameter for return from
route blocks. Like:
log_stderror = false
The grammar of the language defines a coupe of token variants for same purpose:
YES "yes"|"true"|"on"|"enable"
NO "no"|"false"|"off"|"disable"
Where YES is replaced by 1 and NO is replaced by 0:
{YES} { count(); yylval.intval=1;
yy_number_str=yytext; return NUMBER; }
{NO} { count(); yylval.intval=0;
yy_number_str=yytext; return NUMBER; }
In the devel version (upcoming 5.7.0), the evaluation of return mode can be
controlled by core parameter return_mode, allowing to switch to a more
"standard" mode, similar to other scripting languages -- see:
- https://www.kamailio.org/wikidocs/cookbooks/devel/core/#return_mode
Cheers,
Daniel
On 28.04.23 08:14, Patrick Wakano wrote:
Hi list,
Hope you are all well!
I'm using Kamailio version 5.6.4 (installed from the repo
rpm.kamailio.org/centos/7<http://rpm.kamailio.org/centos/7>) and noticed that
every route that uses "return false" is exiting the script, instead of
returning This was not the case on version 5.4.6 as the same script is
running fine.
From this page
https://www.kamailio.org/wikidocs/tutorials/faq/main/#how-is-the-function-return-code-evaluated,
I would think that when a route returns false, it would return -1 and not stop
execution, since negative is equal to false, but it is actually stopping (same
as return 0)...
So, as an example, this test code doesn't work as expected. In case the source
is a public IP, the script doesn't print the "SRC public" it just exits and
then of course every other logic meant to be done is not executed
route[is_src_private]
{
if (is_ip_rfc1918("$si")) {
return true;
}
return false;
#return is_ip_rfc1918("$si"); # thi
[SR-Users] Re: Clarification of 'return false' behaviour
Thanks Henning and Daniel for taking the time to check this out!
I will double check my env but anyway will review my script and follow
Daniel's recommendations!
Hennig, would you be able to disclose the contents of your /root/sip3.txt
file? It really got my interest in this nc usage!
Appreciate your replies!
Kind regards,
Patrick
On Tue, 2 May 2023 at 18:10, Daniel-Constantin Mierla
wrote:
> Hello,
>
> indeed, it is somehow confusing, because in terms of evaluating the return
> code in logical expression, 'false' means the return code was negative and
> 'true' means it was positve.
>
> Then the core keywords 'true' and 'false' are just aliases to 1 and 0 for
> use with core parameters, but their meaning is not related to logical
> evaluation of function's return code.
>
> Someone decided like 20 years ago to have this kind of logical evaluation
> and it continued to be like that till now.
>
> There was a regression at some point when return 0 was no longer exiting,
> being fixed at some point. One may notice the behaviour change if run same
> config before and after.
>
> In general is not good to just return the value from execution of a
> function, but evaluate to true or false and return explicitly own values.
> Instead of
>
> return x()
>
> do:
>
> if(x()) {
>
> return 1;
>
> } else {
>
> return -1;
>
> }
>
> Cheers,
> Daniel
> On 01.05.23 01:10, Patrick Wakano wrote:
>
> Thanks very much for the clarification Daniel! Appreciate it!
> However it does seem that some modules have inconsistencies with return
> values now. So, for instance, the is_ip_rfc918() says it will return true
> or false (
> https://kamailio.org/docs/modules/5.6.x/modules/ipops.html#ipops.f.is_ip_rfc1918
> - most functions of this module return true or false) and then when used
> directly with return, it terminates execution. Based on your explanation,
> it shouldn't return true or false, but likely -1 or 1, which would never be
> considered 'return 0'
> Also, the below code works in version 5.4, but terminates execution in
> version 5.6, so are you aware of changes in this behaviour in version 5.5
> or 5.6 (before the 5.7 changes you mentioned)?
> route[is_src_private]
> {
> return is_ip_rfc1918("$si");
> }
> request_route
> {
> ...
> if (route(is_src_private)) {
> xlog("L_NOTICE", "SRC private\n");
> } else {
> xlog("L_NOTICE", "SRC public\n");
> }
> ...
> }
>
> Best regards!
> Patrick
>
> On Fri, 28 Apr 2023 at 16:29, Daniel-Constantin Mierla
> wrote:
>
>> Hello,
>>
>> false is 0 and it was actually designed for setting global parameters,
>> not for use as comparison with functions return code or as parameter for
>> return from route blocks. Like:
>>
>> log_stderror = false
>>
>> The grammar of the language defines a coupe of token variants for same
>> purpose:
>>
>>
>>YES "yes"|"true"|"on"|"enable"
>>NO "no"|"false"|"off"|"disable"
>>
>> Where YES is replaced by 1 and NO is replaced by 0:
>>
>>{YES} { count(); yylval.intval=1;
>>yy_number_str=yytext; return NUMBER; }
>>{NO} { count(); yylval.intval=0;
>>yy_number_str=yytext; return NUMBER; }
>>
>> In the devel version (upcoming 5.7.0), the evaluation of return mode can
>> be controlled by core parameter return_mode, allowing to switch to a more
>> "standard" mode, similar to other scripting languages -- see:
>>
>> - https://www.kamailio.org/wikidocs/cookbooks/devel/core/#return_mode
>>
>> Cheers,
>> Daniel
>>
>> On 28.04.23 08:14, Patrick Wakano wrote:
>>
>> Hi list,
>> Hope you are all well!
>>
>> I'm using Kamailio version 5.6.4 (installed from the repo
>> rpm.kamailio.org/centos/7) and noticed that every route that uses
>> "return false" is exiting the script, instead of returning This was not
>> the case on version 5.4.6 as the same script is running fine.
>> From this page
>> https://www.kamailio.org/wikidocs/tutorials/faq/main/#how-is-the-function-return-code-evaluated,
>> I would think that when a route returns false, it would return -1 and not
>> stop execution, since negative is equal to false, but it is actually
>> stopping (same as return 0)...
>> So, as an example, this test code doesn't work as expected. In case the
>> source is a public IP, the script doesn't print the "SRC public" it just
>> exits and then of course every other logic meant to be done is not
>> executed
>>
>> route[is_src_private]
>> {
>> if (is_ip_rfc1918("$si")) {
>> return true;
>> }
>> return false;
>> #return is_ip_rfc1918("$si"); *# this doesn't work too in case
>> the $si is a public IP*
>> }
>> request_route
>> {
>> ...
>> if (route(is_src_private)) {
>> xlog("L_NOTICE", "SRC private\n");
>> } else {
>> xlog("L_NOTICE", "SRC public\n");
>> }
>> ...
>> }
>> If is_src_private is changed to return
[SR-Users] Re: Clarification of 'return false' behaviour
Hello,
indeed, it is somehow confusing, because in terms of evaluating the
return code in logical expression, 'false' means the return code was
negative and 'true' means it was positve.
Then the core keywords 'true' and 'false' are just aliases to 1 and 0
for use with core parameters, but their meaning is not related to
logical evaluation of function's return code.
Someone decided like 20 years ago to have this kind of logical
evaluation and it continued to be like that till now.
There was a regression at some point when return 0 was no longer
exiting, being fixed at some point. One may notice the behaviour change
if run same config before and after.
In general is not good to just return the value from execution of a
function, but evaluate to true or false and return explicitly own
values. Instead of
return x()
do:
if(x()) {
return 1;
} else {
return -1;
}
Cheers,
Daniel
On 01.05.23 01:10, Patrick Wakano wrote:
> Thanks very much for the clarification Daniel! Appreciate it!
> However it does seem that some modules have inconsistencies with
> return values now. So, for instance, the is_ip_rfc918() says it will
> return true or false
> (https://kamailio.org/docs/modules/5.6.x/modules/ipops.html#ipops.f.is_ip_rfc1918
> - most functions of this module return true or false) and then when
> used directly with return, it terminates execution. Based on your
> explanation, it shouldn't return true or false, but likely -1 or 1,
> which would never be considered 'return 0'
> Also, the below code works in version 5.4, but terminates execution in
> version 5.6, so are you aware of changes in this behaviour in version
> 5.5 or 5.6 (before the 5.7 changes you mentioned)?
> route[is_src_private]
> {
> return is_ip_rfc1918("$si");
> }
> request_route
> {
> ...
> if (route(is_src_private)) {
> xlog("L_NOTICE", "SRC private\n");
> } else {
> xlog("L_NOTICE", "SRC public\n");
> }
> ...
> }
>
> Best regards!
> Patrick
>
> On Fri, 28 Apr 2023 at 16:29, Daniel-Constantin Mierla
> wrote:
>
> Hello,
>
> false is 0 and it was actually designed for setting global
> parameters, not for use as comparison with functions return code
> or as parameter for return from route blocks. Like:
>
> log_stderror = false
>
> The grammar of the language defines a coupe of token variants for
> same purpose:
>
>
> YES "yes"|"true"|"on"|"enable"
> NO "no"|"false"|"off"|"disable"
>
> Where YES is replaced by 1 and NO is replaced by 0:
>
> {YES} { count(); yylval.intval=1;
> yy_number_str=yytext; return NUMBER; }
> {NO} { count(); yylval.intval=0;
> yy_number_str=yytext; return NUMBER; }
>
> In the devel version (upcoming 5.7.0), the evaluation of return
> mode can be controlled by core parameter return_mode, allowing to
> switch to a more "standard" mode, similar to other scripting
> languages -- see:
>
> -
> https://www.kamailio.org/wikidocs/cookbooks/devel/core/#return_mode
>
> Cheers,
> Daniel
>
> On 28.04.23 08:14, Patrick Wakano wrote:
>> Hi list,
>> Hope you are all well!
>>
>> I'm using Kamailio version 5.6.4 (installed from the repo
>> rpm.kamailio.org/centos/7 ) and
>> noticed that every route that uses "return false" is exiting the
>> script, instead of returning This was not the case on version
>> 5.4.6 as the same script is running fine.
>> From this page
>>
>> https://www.kamailio.org/wikidocs/tutorials/faq/main/#how-is-the-function-return-code-evaluated,
>> I would think that when a route returns false, it would return -1
>> and not stop execution, since negative is equal to false, but it
>> is actually stopping (same as return 0)...
>> So, as an example, this test code doesn't work as expected. In
>> case the source is a public IP, the script doesn't print the "SRC
>> public" it just exits and then of course every other logic meant
>> to be done is not executed
>>
>> route[is_src_private]
>> {
>> if (is_ip_rfc1918("$si")) {
>> return true;
>> }
>> return false;
>> #return is_ip_rfc1918("$si"); *# this doesn't work too in
>> case the $si is a public IP*
>> }
>> request_route
>> {
>> ...
>> if (route(is_src_private)) {
>> xlog("L_NOTICE", "SRC private\n");
>> } else {
>> xlog("L_NOTICE", "SRC public\n");
>> }
>> ...
>> }
>> If is_src_private is changed to return -1 instead of false, then
>> it all works fine.
>>
>> Also, I noticed that the following code will print "TEST: 0" in
>> case the $si is public and then stop execution. So looks like
>> false is
[SR-Users] Re: Clarification of 'return false' behaviour
Hello,
your quoted code below also terminates the execution on Kamailio 5.4.x. Maybe
you could double-check on your installation.
route {
xlog("before\n");
if (route(is_src_private)) {
xlog("L_NOTICE", "SRC private\n");
} else {
xlog("L_NOTICE", "SRC public\n");
}
xlog("after\n");
[…]
}
$ cat /root/sip3.txt | nc -u 127.0.0.1 5060
$ tail /var/log/kamailio.log
May 1 06:30:58 kam03 /usr/sbin/kamailio[5909]: ERROR: {1 10691 INVITE
ud04chatv9q@10.135.0.1}
[SR-Users] Re: Clarification of 'return false' behaviour
Thanks very much for the clarification Daniel! Appreciate it!
However it does seem that some modules have inconsistencies with return
values now. So, for instance, the is_ip_rfc918() says it will return true
or false (
https://kamailio.org/docs/modules/5.6.x/modules/ipops.html#ipops.f.is_ip_rfc1918
- most functions of this module return true or false) and then when used
directly with return, it terminates execution. Based on your explanation,
it shouldn't return true or false, but likely -1 or 1, which would never be
considered 'return 0'
Also, the below code works in version 5.4, but terminates execution in
version 5.6, so are you aware of changes in this behaviour in version 5.5
or 5.6 (before the 5.7 changes you mentioned)?
route[is_src_private]
{
return is_ip_rfc1918("$si");
}
request_route
{
...
if (route(is_src_private)) {
xlog("L_NOTICE", "SRC private\n");
} else {
xlog("L_NOTICE", "SRC public\n");
}
...
}
Best regards!
Patrick
On Fri, 28 Apr 2023 at 16:29, Daniel-Constantin Mierla
wrote:
> Hello,
>
> false is 0 and it was actually designed for setting global parameters, not
> for use as comparison with functions return code or as parameter for return
> from route blocks. Like:
>
> log_stderror = false
>
> The grammar of the language defines a coupe of token variants for same
> purpose:
>
>
>YES "yes"|"true"|"on"|"enable"
>NO "no"|"false"|"off"|"disable"
>
> Where YES is replaced by 1 and NO is replaced by 0:
>
>{YES} { count(); yylval.intval=1;
>yy_number_str=yytext; return NUMBER; }
>{NO} { count(); yylval.intval=0;
>yy_number_str=yytext; return NUMBER; }
>
> In the devel version (upcoming 5.7.0), the evaluation of return mode can
> be controlled by core parameter return_mode, allowing to switch to a more
> "standard" mode, similar to other scripting languages -- see:
>
> - https://www.kamailio.org/wikidocs/cookbooks/devel/core/#return_mode
>
> Cheers,
> Daniel
>
> On 28.04.23 08:14, Patrick Wakano wrote:
>
> Hi list,
> Hope you are all well!
>
> I'm using Kamailio version 5.6.4 (installed from the repo
> rpm.kamailio.org/centos/7) and noticed that every route that uses "return
> false" is exiting the script, instead of returning This was not the
> case on version 5.4.6 as the same script is running fine.
> From this page
> https://www.kamailio.org/wikidocs/tutorials/faq/main/#how-is-the-function-return-code-evaluated,
> I would think that when a route returns false, it would return -1 and not
> stop execution, since negative is equal to false, but it is actually
> stopping (same as return 0)...
> So, as an example, this test code doesn't work as expected. In case the
> source is a public IP, the script doesn't print the "SRC public" it just
> exits and then of course every other logic meant to be done is not
> executed
>
> route[is_src_private]
> {
> if (is_ip_rfc1918("$si")) {
> return true;
> }
> return false;
> #return is_ip_rfc1918("$si"); *# this doesn't work too in case
> the $si is a public IP*
> }
> request_route
> {
> ...
> if (route(is_src_private)) {
> xlog("L_NOTICE", "SRC private\n");
> } else {
> xlog("L_NOTICE", "SRC public\n");
> }
> ...
> }
> If is_src_private is changed to return -1 instead of false, then it all
> works fine.
>
> Also, I noticed that the following code will print "TEST: 0" in case the
> $si is public and then stop execution. So looks like false is really being
> converted to 0, but I guess that's unexpected... anyway apologies if I'm
> missing something obvious
> route[is_src_private]
> {
> $var(t) = false;
> if (is_ip_rfc1918("$si")) {
> $var(t) = true;
> }
> xlog("L_ERR", "TEST: $var(t)\n");
> return $var(t);
> }
>
> I could not find a recent ticket or email related to this situation and
> I've already spent hours trying to understand what is the logic/problem
> here, so would anyone have been across a similar case that could provide
> some insight and clarify what is the expected behaviour of the *false*
> usage (and boolean in general if possible)?
>
> Thank you,
> Kind regards,
> Patrick Wakano
>
> __
> Kamailio - Users Mailing List - Non Commercial Discussions
> To unsubscribe send an email to sr-users-le...@lists.kamailio.org
> Important: keep the mailing list in the recipients, do not reply only to the
> sender!
> Edit mailing list options or unsubscribe:
>
>
> --
> Daniel-Constantin Mierla -- www.asipto.comwww.twitter.com/miconda --
> www.linkedin.com/in/miconda
> Kamailio World Conference - June 5-7, 2023 - www.kamailioworld.com
>
>
__
Kamailio - Users Mailing List - Non Commercial
[SR-Users] Re: Clarification of 'return false' behaviour
Hello,
false is 0 and it was actually designed for setting global parameters,
not for use as comparison with functions return code or as parameter for
return from route blocks. Like:
log_stderror = false
The grammar of the language defines a coupe of token variants for same
purpose:
YES "yes"|"true"|"on"|"enable"
NO "no"|"false"|"off"|"disable"
Where YES is replaced by 1 and NO is replaced by 0:
{YES} { count(); yylval.intval=1;
yy_number_str=yytext; return NUMBER; }
{NO} { count(); yylval.intval=0;
yy_number_str=yytext; return NUMBER; }
In the devel version (upcoming 5.7.0), the evaluation of return mode can
be controlled by core parameter return_mode, allowing to switch to a
more "standard" mode, similar to other scripting languages -- see:
- https://www.kamailio.org/wikidocs/cookbooks/devel/core/#return_mode
Cheers,
Daniel
On 28.04.23 08:14, Patrick Wakano wrote:
> Hi list,
> Hope you are all well!
>
> I'm using Kamailio version 5.6.4 (installed from the repo
> rpm.kamailio.org/centos/7 ) and
> noticed that every route that uses "return false" is exiting the
> script, instead of returning This was not the case on version
> 5.4.6 as the same script is running fine.
> From this page
> https://www.kamailio.org/wikidocs/tutorials/faq/main/#how-is-the-function-return-code-evaluated,
> I would think that when a route returns false, it would return -1 and
> not stop execution, since negative is equal to false, but it is
> actually stopping (same as return 0)...
> So, as an example, this test code doesn't work as expected. In case
> the source is a public IP, the script doesn't print the "SRC public"
> it just exits and then of course every other logic meant to be done is
> not executed
>
> route[is_src_private]
> {
> if (is_ip_rfc1918("$si")) {
> return true;
> }
> return false;
> #return is_ip_rfc1918("$si"); *# this doesn't work too in case
> the $si is a public IP*
> }
> request_route
> {
> ...
> if (route(is_src_private)) {
> xlog("L_NOTICE", "SRC private\n");
> } else {
> xlog("L_NOTICE", "SRC public\n");
> }
> ...
> }
> If is_src_private is changed to return -1 instead of false, then it
> all works fine.
>
> Also, I noticed that the following code will print "TEST: 0" in case
> the $si is public and then stop execution. So looks like false is
> really being converted to 0, but I guess that's unexpected... anyway
> apologies if I'm missing something obvious
> route[is_src_private]
> {
> $var(t) = false;
> if (is_ip_rfc1918("$si")) {
> $var(t) = true;
> }
> xlog("L_ERR", "TEST: $var(t)\n");
> return $var(t);
> }
>
> I could not find a recent ticket or email related to this situation
> and I've already spent hours trying to understand what is the
> logic/problem here, so would anyone have been across a similar case
> that could provide some insight and clarify what is the expected
> behaviour of the *false* usage (and boolean in general if possible)?
>
> Thank you,
> Kind regards,
> Patrick Wakano
>
> __
> Kamailio - Users Mailing List - Non Commercial Discussions
> To unsubscribe send an email to sr-users-le...@lists.kamailio.org
> Important: keep the mailing list in the recipients, do not reply only to the
> sender!
> Edit mailing list options or unsubscribe:
--
Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Kamailio World Conference - June 5-7, 2023 - www.kamailioworld.com
__
Kamailio - Users Mailing List - Non Commercial Discussions
To unsubscribe send an email to sr-users-le...@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the
sender!
Edit mailing list options or unsubscribe:
