i have stored in htable a key_value=0 with key_type=1, i.e., string.
then i have this piece of test code:
if (defined($sht(htable=>$var(carrier_key)::id))) { xlog("L_INFO", "$sht(htable=>$var(carrier_key)::id) is defined\n"); } else { xlog("L_INFO", "$sht(htable=>$var(carrier_key)::id) is NOT defined\n"); }; $var(carrier_id) = $sht(htable=>$var(carrier_key)::id); if ($var(carrier_id) == (int)0) { xlog("L_INFO", "$sht(htable=>$var(carrier_key)::id) is not found\n"); } else { xlog("L_INFO", "$sht(htable=>$var(carrier_key)::id) is found\n"); };
and when the piece is executed, this is printed to syslog:
Oct 15 12:20:33 squeeze /usr/sbin/trunk-proxy[2915]: INFO: 0 is defined Oct 15 12:20:33 squeeze /usr/sbin/trunk-proxy[2915]: INFO: 0 is not found
i understand the first line, because the entry is in the htable, but how is it possible that string "0" is equal to int 0?
-- juha
On Oct 15, 2010 at 12:29, Juha Heinanen jh@tutpro.com wrote:
i have stored in htable a key_value=0 with key_type=1, i.e., string.
then i have this piece of test code:
if (defined($sht(htable=>$var(carrier_key)::id))) { xlog("L_INFO", "$sht(htable=>$var(carrier_key)::id) is defined\n"); } else { xlog("L_INFO", "$sht(htable=>$var(carrier_key)::id) is NOT defined\n"); }; $var(carrier_id) = $sht(htable=>$var(carrier_key)::id); if ($var(carrier_id) == (int)0) { xlog("L_INFO", "$sht(htable=>$var(carrier_key)::id) is not found\n"); } else { xlog("L_INFO", "$sht(htable=>$var(carrier_key)::id) is found\n"); };and when the piece is executed, this is printed to syslog:
Oct 15 12:20:33 squeeze /usr/sbin/trunk-proxy[2915]: INFO: 0 is defined Oct 15 12:20:33 squeeze /usr/sbin/trunk-proxy[2915]: INFO: 0 is not found
i understand the first line, because the entry is in the htable, but how is it possible that string "0" is equal to int 0?
Because "==" works only with arguments of the same type, 0 it's autoconverted to "0". The alternative would be to log an error.
Here are the rules for ==: /* if left is string, eval left & right as string and use string diff. * if left is int eval as int using int diff * if left is undef, look at right and convert to right type */
Andrei
Andrei Pelinescu-Onciul writes:
Because "==" works only with arguments of the same type, 0 it's autoconverted to "0". The alternative would be to log an error.
andrei,
please log an error, because it is hard to remember this uncommon comparison rule and seeing an error message would reveal the problem fast.
Here are the rules for ==: /* if left is string, eval left & right as string and use string diff.
- if left is int eval as int using int diff
- if left is undef, look at right and convert to right type
*/
getting back to the example code, how can i check if value of a var is int 0? is there an is_int function?
-- juha
On 10/15/10 12:44 PM, Juha Heinanen wrote:
Andrei Pelinescu-Onciul writes:
Because "==" works only with arguments of the same type, 0 it's autoconverted to "0". The alternative would be to log an error.
andrei,
please log an error, because it is hard to remember this uncommon comparison rule and seeing an error message would reveal the problem fast.
Not sure this is a good idea. This kind of comparison behaves the same from many versions ago.
Note that all pseudo-variables from kamailio keep all the time the string representation of the value, that was from day one, back in era of ser 0.9.x where the PV code was part of xlog module.
I don't think a strict type checking is suitable for configuration file - e.g., if I want to check value in cseq, don't want to get lost in type conversions.
If there is going to be such error messages, they must be enclosed in a config parameter.
Cheers, Daniel
Here are the rules for ==: /* if left is string, eval left& right as string and use string diff.
- if left is int eval as int using int diff
- if left is undef, look at right and convert to right type
*/
getting back to the example code, how can i check if value of a var is int 0? is there an is_int function?
-- juha
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Daniel-Constantin Mierla writes:
I don't think a strict type checking is suitable for configuration file
- e.g., if I want to check value in cseq, don't want to get lost in type
conversions.
If there is going to be such error messages, they must be enclosed in a config parameter.
yes, there could be a config parameter "warn_about_implicit_type_conversions" or something like that. i would definitely turn it on, since it would not be a big deal for me to add (int) or (string) in front of a variable when i want type conversion to be done in order to avoid config mistakes that get unnoticed.
-- juha
On 10/15/10 1:43 PM, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
I don't think a strict type checking is suitable for configuration file
- e.g., if I want to check value in cseq, don't want to get lost in type
conversions.
If there is going to be such error messages, they must be enclosed in a config parameter.
yes, there could be a config parameter "warn_about_implicit_type_conversions" or something like that. i would definitely turn it on, since it would not be a big deal for me to add (int) or (string) in front of a variable when i want type conversion to be done in order to avoid config mistakes that get unnoticed.
At the end of the day, one can write entire routing logic directly in C code.
Config language is complex enough, adding such things to it will make it really unusable. Bear in mind that config is for sys admins not for programmers. They operate the platform, then should care only of SIP layer (which is alone difficult enough), not typed of variables and heavy programming languages.
Btw, what mistakes really can happen? That string "0" is equal with 0? It is this way for so many years now.
Either we focus to make the config file easier to understand and use, or drop it and tell everything has to be written in C and the 50-100 of us, developers, will use it.
Cheers, Daniel
daniel,
after your rant, please tell a non-programmer, how he/she can easily test if a var holds integer 0 value?
-- juha
Juha,
On 10/15/10 4:32 PM, Juha Heinanen wrote:
daniel,
after your rant,
rant?!? maybe you got the message wrong. It was about the purpose of configuration file and the target users for it.
please tell a non-programmer, how he/she can easily test if a var holds integer 0 value?
I don't see the relation of this question with auto-conversion debate and type checking.
The variable is set somehow, either taken from database of directly in config. Who does the logic know what comes there. If I do $var(x) = 1; I know it is integer. I haven't found a need to test the type of variable so far, but, if someone has an there is no function for finding out the type of value, it can be written. Avpops module has one for avps, but I haven't heard many using it -- in the beginning people use it to test if avp is set or not, now everyone is testing against $null.
So, really, this is not anything like flame war, just making sure we don't rewrite c interpreter, because nobody is going to use it.
Cheers, Daniel
Daniel-Constantin Mierla writes:
rant?!? maybe you got the message wrong. It was about the purpose of configuration file and the target users for it.
your message was very emotional. you defined the target users in your message. i have not seen that discussed or agreed earlier. my claim is that current config language very much resembles a programming language.
please tell a non-programmer, how he/she can easily test if a var holds integer 0 value?
I don't see the relation of this question with auto-conversion debate and type checking.
it has, because if target is a non-programmer, then it should be very easy to do. that was the problem where this whole discussion started.
The variable is set somehow, either taken from database of directly in config. Who does the logic know what comes there. If I do $var(x) = 1; I know it is integer. I haven't found a need to test the type of variable so far, but, if someone has an there is no function for finding out the type of value, it can be written.
here is a real world example for you: make a single htable query and find out, if the resulting value is string "0" or if there was no result at all. for performance reasons i don't accept answer where the query is done two times.
So, really, this is not anything like flame war, just making sure we don't rewrite c interpreter, because nobody is going to use it.
you are exaggerating. there is big difference between type safety and c language programming.
-- juha
On 10/15/10 5:03 PM, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
rant?!? maybe you got the message wrong. It was about the purpose of configuration file and the target users for it.
your message was very emotional. you defined the target users in your message. i have not seen that discussed or agreed earlier.
well, somehow is what I see everywhere I deal with. Barely found programmers to manage operational systems, being it web servers, mail servers, voip servers, a.s.o.
my claim is that current config language very much resembles a programming language.
That is quite some problem imo, so instead of make it more complex, I will try to reduce it complexity and make it more use friendly.
please tell a non-programmer, how he/she can easily test if a var holds integer 0 value?
I don't see the relation of this question with auto-conversion debate and type checking.
it has, because if target is a non-programmer, then it should be very easy to do. that was the problem where this whole discussion started.
I don't think the target is to have a generic programming language, where the admin doesn't know what comes and from where, so it has to do a lot of checks to find out.
The variable is set somehow, either taken from database of directly in config. Who does the logic know what comes there. If I do $var(x) = 1; I know it is integer. I haven't found a need to test the type of variable so far, but, if someone has an there is no function for finding out the type of value, it can be written.
here is a real world example for you: make a single htable query and find out, if the resulting value is string "0" or if there was no result at all. for performance reasons i don't accept answer where the query is done two times.
Yet the performance is another topic. How much penalty a htable query could bring? If you look into the c code of many functions there are lot of too many safety checks that can be removed. I think we can do more processing than the pipe can handle.
So, really, this is not anything like flame war, just making sure we don't rewrite c interpreter, because nobody is going to use it.
you are exaggerating. there is big difference between type safety and c language programming.
This is one step in that direction rather than opposite. So my concern was not to end up rewriting it.
Cheers, Daniel
On Oct 15, 2010 at 16:26, Daniel-Constantin Mierla miconda@gmail.com wrote:
On 10/15/10 1:43 PM, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
I don't think a strict type checking is suitable for configuration file
- e.g., if I want to check value in cseq, don't want to get lost in type
conversions.
If there is going to be such error messages, they must be enclosed in a config parameter.
yes, there could be a config parameter "warn_about_implicit_type_conversions" or something like that. i would definitely turn it on, since it would not be a big deal for me to add (int) or (string) in front of a variable when i want type conversion to be done in order to avoid config mistakes that get unnoticed.
At the end of the day, one can write entire routing logic directly in C code.
Config language is complex enough, adding such things to it will make it really unusable. Bear in mind that config is for sys admins not for programmers. They operate the platform, then should care only of SIP layer (which is alone difficult enough), not typed of variables and heavy programming languages.
Btw, what mistakes really can happen? That string "0" is equal with 0? It is this way for so many years now.
Either we focus to make the config file easier to understand and use, or drop it and tell everything has to be written in C and the 50-100 of us, developers, will use it.
Actually there is a more dangerous thing here. All this nice features might hide script errors up to runtime. With a more strict type checking (and different operators for ints and strings), much more checking can be done at startup. In my opinion this would be more user friendly, then allowing everything and try to guess at runtime what the user really wanted. It's much more important to make sure the script is ok before starting, then to save someone some typing.
Regarding this case, I agree that changing it now for 3.1 is a bad idea and this is also not the best example of how things could go wrong.
Andrei
On 10/15/10 4:36 PM, Andrei Pelinescu-Onciul wrote:
On Oct 15, 2010 at 16:26, Daniel-Constantin Mierlamiconda@gmail.com wrote:
On 10/15/10 1:43 PM, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
I don't think a strict type checking is suitable for configuration file
- e.g., if I want to check value in cseq, don't want to get lost in type
conversions.
If there is going to be such error messages, they must be enclosed in a config parameter.
yes, there could be a config parameter "warn_about_implicit_type_conversions" or something like that. i would definitely turn it on, since it would not be a big deal for me to add (int) or (string) in front of a variable when i want type conversion to be done in order to avoid config mistakes that get unnoticed.
At the end of the day, one can write entire routing logic directly in C code.
Config language is complex enough, adding such things to it will make it really unusable. Bear in mind that config is for sys admins not for programmers. They operate the platform, then should care only of SIP layer (which is alone difficult enough), not typed of variables and heavy programming languages.
Btw, what mistakes really can happen? That string "0" is equal with 0? It is this way for so many years now.
Either we focus to make the config file easier to understand and use, or drop it and tell everything has to be written in C and the 50-100 of us, developers, will use it.
Actually there is a more dangerous thing here. All this nice features might hide script errors up to runtime. With a more strict type checking (and different operators for ints and strings), much more checking can be done at startup. In my opinion this would be more user friendly, then allowing everything and try to guess at runtime what the user really wanted. It's much more important to make sure the script is ok before starting, then to save someone some typing.
Regarding this case, I agree that changing it now for 3.1 is a bad idea and this is also not the best example of how things could go wrong.
Andrei,
besides that bad things can happen always :-) , so far nobody complained about such cases, but about complexity to understand and build configuration files.
If we make it more C like, for sure won't get new people or businesses jumping in. Paying a programmer for sysadmin job won't work, maybe not only because of money, but because of people's own expectation. And perhaps is were we get in the trap, we are programmers and we would like to be same, but as said in the previous email, we end up to close a circle of 50-100 people.
From the first time avps were introduced that they can hold string or integers. xlog introduced specifiers holding all the time strings and later used for pseudo-variables, that is more than 5 years ago and all went fine so far.
Changing current behavior will be killing, using new operators (iirc, you added something with le, lt, ...) would be an option, but we add more to the confusion of what and how to use.
Cheers, Daniel
Daniel-Constantin Mierla writes:
Changing current behavior will be killing, using new operators (iirc, you added something with le, lt, ...) would be an option, but we add more to the confusion of what and how to use.
i agree with daniel here. introducing new operators is not user friendly. for me enough would be an option that warns about all implicit type conversions. it should not bother daniel either, because he does not need to use that option.
-- juha
On Oct 15, 2010 at 17:04, Daniel-Constantin Mierla miconda@gmail.com wrote:
On 10/15/10 4:36 PM, Andrei Pelinescu-Onciul wrote:
On Oct 15, 2010 at 16:26, Daniel-Constantin Mierlamiconda@gmail.com wrote:
On 10/15/10 1:43 PM, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
I don't think a strict type checking is suitable for configuration file
- e.g., if I want to check value in cseq, don't want to get lost in type
conversions.
If there is going to be such error messages, they must be enclosed in a config parameter.
yes, there could be a config parameter "warn_about_implicit_type_conversions" or something like that. i would definitely turn it on, since it would not be a big deal for me to add (int) or (string) in front of a variable when i want type conversion to be done in order to avoid config mistakes that get unnoticed.
At the end of the day, one can write entire routing logic directly in C code.
Config language is complex enough, adding such things to it will make it really unusable. Bear in mind that config is for sys admins not for programmers. They operate the platform, then should care only of SIP layer (which is alone difficult enough), not typed of variables and heavy programming languages.
Btw, what mistakes really can happen? That string "0" is equal with 0? It is this way for so many years now.
Either we focus to make the config file easier to understand and use, or drop it and tell everything has to be written in C and the 50-100 of us, developers, will use it.
Actually there is a more dangerous thing here. All this nice features might hide script errors up to runtime. With a more strict type checking (and different operators for ints and strings), much more checking can be done at startup. In my opinion this would be more user friendly, then allowing everything and try to guess at runtime what the user really wanted. It's much more important to make sure the script is ok before starting, then to save someone some typing.
Regarding this case, I agree that changing it now for 3.1 is a bad idea and this is also not the best example of how things could go wrong.
Andrei,
besides that bad things can happen always :-) , so far nobody complained about such cases, but about complexity to understand and build configuration files.
If we make it more C like, for sure won't get new people or businesses jumping in. Paying a programmer for sysadmin job won't work, maybe not only because of money, but because of people's own expectation. And perhaps is were we get in the trap, we are programmers and we would like to be same, but as said in the previous email, we end up to close a circle of 50-100 people.
So it's better to have hidden errors in script that are quite difficult to find, rather then forcing people to use a variable type? Most non-programmer people will use strings anyway and they wouldn't be affected by this. For me when it comes to production servers any extra config checks it's worth the formidable effort to remember to use a different operator for integers and to declare variable that are supposed to hold integers.
From the first time avps were introduced that they can hold string or integers. xlog introduced specifiers holding all the time strings and later used for pseudo-variables, that is more than 5 years ago and all went fine so far.
Changing current behavior will be killing, using new operators (iirc, you added something with le, lt, ...) would be an option, but we add more to the confusion of what and how to use.
Andrei
On 10/15/10 5:14 PM, Andrei Pelinescu-Onciul wrote:
On Oct 15, 2010 at 17:04, Daniel-Constantin Mierlamiconda@gmail.com wrote:
[...] Andrei,
besides that bad things can happen always :-) , so far nobody complained about such cases, but about complexity to understand and build configuration files.
If we make it more C like, for sure won't get new people or businesses jumping in. Paying a programmer for sysadmin job won't work, maybe not only because of money, but because of people's own expectation. And perhaps is were we get in the trap, we are programmers and we would like to be same, but as said in the previous email, we end up to close a circle of 50-100 people.
So it's better to have hidden errors in script that are quite difficult to find, rather then forcing people to use a variable type?
First we need to have those people in order to force them to do something.
My concern was strictly related to this aspect, where nobody will even try it because they don't understand the config language and how to build the routing logic.
Most non-programmer people will use strings anyway and they wouldn't be affected by this. For me when it comes to production servers any extra config checks it's worth the formidable effort to remember to use a different operator for integers and to declare variable that are supposed to hold integers.
Like Juha and me, you are a programmer, probably the most "heavyweight" low level programming in this project. Just imagine how many like you are around and going to work as voip platform administrators.
Even we like it or not, non-type-safety languages such as perl, shell or python rule the sys admin world.
If we are going to build it for us, C is fine for config, anyhow the functions in config are wrappers to C code.
Then, if we change existing behaviour dramatically, many people will move away since cannot handle it any more.
Now, to conclude Juha's request about config parameter controlling printing of a message when doing conversion, it is fine.
Cheers, Daniel
2010/10/15 Daniel-Constantin Mierla miconda@gmail.com:
Even we like it or not, non-type-safety languages such as perl, shell or python rule the sys admin world.
Said that I would like to expose a proposal for comparisons:
1) Never do implicit type conversion. This is, a string is NEVER equal to an integer:
if "0" == 0 => false if "" == 0 => false if "asdasd" == 0 => false
2) An integer is NEVER equal to a string:
if 0 == "0" => false if 0 == "" => false if 0 == "asdasd" => false
3) Integer 0 is not equal to NULL:
if 0 == NULL => false
4) Empty string is not equal to NULL:
if "" == NULL => false
5) Integer 0 is true:
if 0 => true
6) Empty string is true:
if "" => true
The only point I'm not sure is the last one (6). In some high level languages (as Ruby) checking an empty string returns true. However in other languages (as ActionScript) it returns false.
2010/10/15 Iñaki Baz Castillo ibc@aliax.net:
- Never do implicit type conversion. This is, a string is NEVER equal
to an integer:
if "0" == 0 => false if "" == 0 => false if "asdasd" == 0 => false
- An integer is NEVER equal to a string:
if 0 == "0" => false if 0 == "" => false if 0 == "asdasd" => false
- Integer 0 is not equal to NULL:
if 0 == NULL => false
- Empty string is not equal to NULL:
if "" == NULL => false
- Integer 0 is true:
if 0 => true
- Empty string is true:
if "" => true
These simple rules avoid stupid problems (as they occur in PHP):
http://www.otton.org/2008/08/06/stupid-php-tricks-true-false-comparison/
On Oct 15, 2010 at 13:44, Juha Heinanen jh@tutpro.com wrote:
Andrei Pelinescu-Onciul writes:
Because "==" works only with arguments of the same type, 0 it's autoconverted to "0". The alternative would be to log an error.
andrei,
please log an error, because it is hard to remember this uncommon comparison rule and seeing an error message would reveal the problem fast.
Here are the rules for ==: /* if left is string, eval left & right as string and use string diff.
- if left is int eval as int using int diff
- if left is undef, look at right and convert to right type
*/
getting back to the example code, how can i check if value of a var is int 0? is there an is_int function?
No, there is no is_int function, but you could use a hack:
if (($v == 0) && ($v + 0 == (str)0))
will be true only if $v is int and == 0 ($v == 0 makes sure that $v!="").
Andrei
Andrei Pelinescu-Onciul writes:
No, there is no is_int function, but you could use a hack:
if (($v == 0) && ($v + 0 == (str)0))
will be true only if $v is int and == 0 ($v == 0 makes sure that $v!="").
daniel,
here you go. is that in your opinion something that a non-programmer could easily figure out? if not, perhaps we should do something about it.
-- juha
2010/10/15 Juha Heinanen jh@tutpro.com:
No, there is no is_int function, but you could use a hack:
if (($v == 0) && ($v + 0 == (str)0))
will be true only if $v is int and == 0 ($v == 0 makes sure that $v!="").
daniel,
here you go. is that in your opinion something that a non-programmer could easily figure out?
I think the above is not realistic for a common SR/Kamailio admin.
2010/10/15 Juha Heinanen jh@tutpro.com:
No, there is no is_int function, but you could use a hack:
if (($v == 0) && ($v + 0 == (str)0))
will be true only if $v is int and == 0 ($v == 0 makes sure that $v!="").
daniel,
here you go. is that in your opinion something that a non-programmer could easily figure out? if not, perhaps we should do something about it.
In Kamailio 1.5 I experiment this problem very often:
Usually I get data from a DB table in which some fields are INT (allowing NULL). Possible values are NULL or integers from 0 to N. Trying to figure if the column has value 0 is a pain.
On 10/15/10 7:46 PM, Iñaki Baz Castillo wrote:
[...] In Kamailio 1.5 I experiment this problem very often:
Usually I get data from a DB table in which some fields are INT (allowing NULL). Possible values are NULL or integers from 0 to N. Trying to figure if the column has value 0 is a pain.
Have you tried: if($var(x)==0) ?
Cheers, Daniel
2010/10/15 Daniel-Constantin Mierla miconda@gmail.com:
Usually I get data from a DB table in which some fields are INT (allowing NULL). Possible values are NULL or integers from 0 to N. Trying to figure if the column has value 0 is a pain.
Have you tried: if($var(x)==0) ?
Yes, that would work, but it's not what I need:
I retrieve a table column value via a DB query and store it in an AVP. Such column can store NULL, 0, 1, 2 ... 8. How can I check if the AVP has an integer value (including 0)?:
1) In case I retrieve 1...8 from the database:
- if $avp(column) => true - if $avp(column) >=0 => true
2) In case I retrieve 0 or NULL from the database:
- if $avp(column) => false - if $avp(column) >=0 => ERROR (invalid comparison)
So there is no way to determine if the retrieved value is *any* integer (including 0), is there?
PS: I *strongly* hate the fact that 0 is threated as "false" or "non true", why?
Regards.
2010/10/15 Iñaki Baz Castillo ibc@aliax.net:
- In case I retrieve 1...8 from the database:
- if $avp(column) => true - if $avp(column) >=0 => true
- In case I retrieve 0 or NULL from the database:
- if $avp(column) => false - if $avp(column) >=0 => ERROR (invalid comparison)
So there is no way to determine if the retrieved value is *any* integer (including 0), is there?
A terrible hack:
if $(avp(column){s.len}) > 0 && ...
This is, in case the valus is an integer (including 0) its string legth is greater than 0. But this is a non ellegant workaround.
2010/10/15 Andrei Pelinescu-Onciul andrei@iptel.org:
Because "==" works only with arguments of the same type, 0 it's autoconverted to "0". The alternative would be to log an error.
Here are the rules for ==: /* if left is string, eval left & right as string and use string diff. * if left is int eval as int using int diff * if left is undef, look at right and convert to right type */
Hi, IMHO it's important not to "imitate" unexpected comparissions as they occur in the "great" PHP language:
http://www.otton.org/2008/08/06/stupid-php-tricks-true-false-comparison/
-
Andrei Pelinescu-Onciul -
Daniel-Constantin Mierla -
Iñaki Baz Castillo -
Juha Heinanen