19 Feb
2009
19 Feb
'09
11:50 p.m.
Module: sip-router
Branch: andrei/switch
Commit: 8c09d09b62681ae4e25709cd291796880dfb91e6
URL:
http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=8c09d09…
Author: Andrei Pelinescu-Onciul <andrei(a)iptel.org>
Committer: Andrei Pelinescu-Onciul <andrei(a)iptel.org>
Date: Thu Feb 19 23:48:34 2009 +0100
script parsing: string switch support
- switch() modified to work on string if the first case contains a
string as the label
- switch() support for regular expressions. Regular expression
are prefixed by `/`. E.g.:
switch("a"){
case / ""+"["+"a"+"bc" +"]" :
log(1, "case a:a\n");
break;
case "b":
log(1, "case a:b\n");
break;
}
---
cfg.y | 124 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++------
1 files changed, 112 insertions(+), 12 deletions(-)
diff --git a/cfg.y b/cfg.y
index e1758bf..0ebb3a9 100644
--- a/cfg.y
+++ b/cfg.y
@@ -215,7 +215,11 @@ static struct socket_id* mk_listen_id2(struct name_lst*, int, int);
static void free_name_lst(struct name_lst* lst);
static void free_socket_id_lst(struct socket_id* i);
-static struct case_stms* mk_case_stm(struct rval_expr* ct, struct action* a);
+static struct case_stms* mk_case_stm(struct rval_expr* ct, int is_re,
+ struct action* a, int* err);
+static int case_check_type(struct case_stms* stms);
+static int case_check_default(struct case_stms* stms);
+
%}
@@ -1793,10 +1797,12 @@ ct_rval: rval_expr {
$$=0;
if (!rve_is_constant($1)){
yyerror("constant expected");
- }else if (!rve_check_type((enum rval_type*)&i_tmp, $1, 0, 0 ,0)){
+ /*
+ } else if (!rve_check_type((enum rval_type*)&i_tmp, $1, 0, 0 ,0)){
yyerror("invalid expression (bad type)");
}else if (i_tmp!=RV_INT){
yyerror("invalid expression type, int expected\n");
+ */
}else
$$=$1;
}
@@ -1805,28 +1811,38 @@ single_case:
CASE ct_rval COLON actions {
$$=0;
if ($2==0) yyerror ("bad case label");
- else if (($$=mk_case_stm($2, $4))==0){
- yyerror("internal error: memory allocation failure");
+ else if ((($$=mk_case_stm($2, 0, $4, &i_tmp))==0) && (i_tmp==-10)){
+ YYABORT;
+ }
+ }
+| CASE SLASH ct_rval COLON actions {
+ $$=0;
+ if ($3==0) yyerror ("bad case label");
+ else if ((($$=mk_case_stm($3, 1, $5, &i_tmp))==0) && (i_tmp==-10)){
YYABORT;
}
}
| CASE ct_rval COLON {
$$=0;
if ($2==0) yyerror ("bad case label");
- else if (($$=mk_case_stm($2, 0))==0){
- yyerror("internal error: memory allocation failure");
+ else if ((($$=mk_case_stm($2, 0, 0, &i_tmp))==0) && (i_tmp==-10)){
+ YYABORT;
+ }
+ }
+ | CASE SLASH ct_rval COLON {
+ $$=0;
+ if ($3==0) yyerror ("bad case label");
+ else if ((($$=mk_case_stm($3, 1, 0, &i_tmp))==0) && (i_tmp==-10)){
YYABORT;
}
}
| DEFAULT COLON actions {
- if (($$=mk_case_stm(0, $3))==0){
- yyerror("internal error: memory allocation failure");
+ if ((($$=mk_case_stm(0, 0, $3, &i_tmp))==0) && (i_tmp=-10)){
YYABORT;
}
}
| DEFAULT COLON {
- if (($$=mk_case_stm(0, 0))==0){
- yyerror("internal error: memory allocation failure");
+ if ((($$=mk_case_stm(0, 0, 0, &i_tmp))==0) && (i_tmp==-10)){
YYABORT;
}
}
@@ -1854,6 +1870,12 @@ switch_cmd:
$$=0;
if ($2==0) yyerror("bad expression in switch(...)");
else if ($4==0) yyerror ("bad switch body");
+ else if (case_check_default($4)!=0)
+ yyerror_at(&$2->fpos, "bad switch(): too many "
+ "\"default:\" labels\n");
+ else if (case_check_type($4)!=0)
+ yyerror_at(&$2->fpos, "bad switch(): mixed integer and"
+ " string/RE cases not allowed\n");
else{
$$=mk_action(SWITCH_T, 2, RVE_ST, $2, CASE_ST, $4);
if ($$==0) {
@@ -2910,15 +2932,52 @@ static void free_socket_id_lst(struct socket_id* lst)
}
-static struct case_stms* mk_case_stm(struct rval_expr* ct, struct action* a)
+/** create a temporary case statmenet structure.
+ * *err will be filled in case of error (return == 0):
+ * -1 - non constant expression
+ * -2 - expression error (bad type)
+ * -10 - memory allocation error
+ */
+static struct case_stms* mk_case_stm(struct rval_expr* ct, int is_re,
+ struct action* a, int* err)
{
struct case_stms* s;
+ struct rval_expr* bad_rve;
+ enum rval_type type, bad_t, exp_t;
+ enum match_str_type t;
+
+ t=MATCH_UNKNOWN;
+ if (ct){
+ /* if ct!=0 => case, else if ct==0 is a default */
+ if (!rve_is_constant(ct)){
+ yyerror_at(&ct->fpos, "non constant expression in case");
+ *err=-1;
+ return 0;
+ }
+ if (rve_check_type(&type, ct, &bad_rve, &bad_t, &exp_t)!=1){
+ yyerror_at(&ct->fpos, "bad expression: type mismatch:"
+ " %s instead of %s at (%d,%d)",
+ rval_type_name(bad_t), rval_type_name(exp_t),
+ bad_rve->fpos.s_line, bad_rve->fpos.s_col);
+ *err=-2;
+ return 0;
+ }
+ if (is_re)
+ t=MATCH_RE;
+ else if (type==RV_STR)
+ t=MATCH_STR;
+ else
+ t=MATCH_INT;
+ }
+
s=pkg_malloc(sizeof(*s));
if (s==0) {
- LOG(L_CRIT,"ERROR: cfg. parser: out of memory.\n");
+ yyerror("internal error: memory allocation failure");
+ *err=-10;
} else {
memset(s, 0, sizeof(*s));
s->ct_rve=ct;
+ s->type=t;
s->actions=a;
s->next=0;
s->append=0;
@@ -2926,6 +2985,47 @@ static struct case_stms* mk_case_stm(struct rval_expr* ct, struct
action* a)
return s;
}
+
+/*
+ * @return 0 on success, -1 on error.
+ */
+static int case_check_type(struct case_stms* stms)
+{
+ struct case_stms* c;
+ struct case_stms* s;
+
+ for(c=stms; c ; c=c->next){
+ if (!c->ct_rve) continue;
+ for (s=c->next; s; s=s->next){
+ if (!s->ct_rve) continue;
+ if ((s->type!=c->type) &&
+ !( (c->type==MATCH_STR || c->type==MATCH_RE) &&
+ (s->type==MATCH_STR || s->type==MATCH_RE) ) ){
+ yyerror_at(&s->ct_rve->fpos, "type mismatch in case");
+ return -1;
+ }
+ }
+ }
+ return 0;
+}
+
+
+/*
+ * @return 0 on success, -1 on error.
+ */
+static int case_check_default(struct case_stms* stms)
+{
+ struct case_stms* c;
+ int default_no;
+
+ default_no=0;
+ for(c=stms; c ; c=c->next)
+ if (c->ct_rve==0) default_no++;
+ return (default_no<=1)?0:-1;
+}
+
+
+
/*
int main(int argc, char ** argv)
{
20 Feb
20 Feb
10:15 a.m.
New subject: [SR-Dev] script parsing: string switch support
Hello Andrei,
On 02/20/2009 12:50 AM, Andrei Pelinescu-Onciul wrote:
[...]
script parsing: string switch support
that's great, thanks. From the next example, to understand the the case
can take expression that evaluates to static strings or integers?
Now, with while and switch in there I can work to get most of my configs
working with sip-router.
Cheers,
Daniel
- switch() modified to work on string if the first
case contains a
string as the label
- switch() support for regular expressions. Regular expression
are prefixed by `/`. E.g.:
switch("a"){
case / ""+"["+"a"+"bc" +"]" :
log(1, "case a:a\n");
break;
case "b":
log(1, "case a:b\n");
break;
}
--
Daniel-Constantin Mierla
http://www.asipto.com
12:22 p.m.
New subject: [SR-Dev] script parsing: string switch support
On Feb 20, 2009 at 11:15, Daniel-Constantin Mierla <miconda(a)gmail.com> wrote:
Hello Andrei,
On 02/20/2009 12:50 AM, Andrei Pelinescu-Onciul wrote:
Yes.
There are the following restriction:
- case labels must be static (no vars allowed)
- in the same switch you can have only one type of case labels: strings
or integers (1)
- the first case label sets the required type for all the others
(so if your first case label is a string => all the other must be
strings, if it's an integer all the other must be integers).
(1) - could be changed in some cases (e.g. string case with some int
label allowed, which could be automatically converted to string), but I
think it would too confusing and I disallowed it (in general having
mixed types in a switch() are 99% an error).
I still think that using a different switch() name for strings will be
less confusing (e.g. switch() for integers and match() for strings).
Any opinion on how to differentiate regular expressions from strings?
Right now a '/' in front means a regular expression (but there's no way
to specify case insensitive match for example).
[...]
script parsing: string switch support
that's great, thanks. From the next example, to understand the the case
can take expression that evaluates to static strings or integers?
Now, with while and switch in there I can work to get most of my configs
working with sip-router.
Warning: the while works only with integers :-)
Andrei
2:03 p.m.
New subject: [SR-Dev] script parsing: string switch support
On 20-02 12:22, Andrei Pelinescu-Onciul wrote:
On Feb 20, 2009 at 11:15, Daniel-Constantin Mierla
<miconda(a)gmail.com> wrote:
I would suggest to convert numbers to strings in this case automatically. For
most people things get more confusing with the increasing amount of details
they have to remember about the configuration language.
This is similar to the difference between
if (method == INVITE) and if (method == "INVITE")
I guess most people won't be able to tell you the difference if you asked them.
I would not assume that mixed integers and strings are 99% errors, we don't
really know what people have in their configuration scripts and why, so this
assumption is IMHO not justified.
Hello Andrei,
On 02/20/2009 12:50 AM, Andrei Pelinescu-Onciul wrote:
Yes.
There are the following restriction:
- case labels must be static (no vars allowed)
- in the same switch you can have only one type of case labels: strings
or integers (1)
- the first case label sets the required type for all the others
(so if your first case label is a string => all the other must be
strings, if it's an integer all the other must be integers).
(1) - could be changed in some cases (e.g. string case with some int
label allowed, which could be automatically converted to string), but I
think it would too confusing and I disallowed it (in general having
mixed types in a switch() are 99% an error). [...]
script parsing: string switch support
that's great, thanks. From the next example, to understand the the case
can take expression that evaluates to static strings or integers? I still think that using a different switch() name for
strings will be
less confusing (e.g. switch() for integers and match() for strings).
Yes, I like match for strings better too, especially if regular expression
matching is involved.
Any opinion on how to differentiate regular
expressions from strings?
Right now a '/' in front means a regular expression (but there's no way
to specify case insensitive match for example).
How about enclosing regular expressions in a pair of // like in awk or
perl. It would be possible to introduce a flag for case-insensitive matching, something
like:
i/regex/
For example:
case i/From/:
my two cents, Jan.
2:25 p.m.
New subject: [SR-Dev] script parsing: string switch support
On Feb 20, 2009 at 14:03, Jan Janak <jan(a)iptel.org> wrote:
On 20-02 12:22, Andrei Pelinescu-Onciul wrote:
This would only make sense if we use match() for strings and switch()
for ints. Otherwise it would be too confusing.
Anyway I don't think the amount of details of the configuration language
is ever a problem, as long as one gets meaningful error messages when
checking the config (and before ser startup).
The other approaches trade-off less config details for guessing what the
user intended, which IMO is much more dangerous. Is much better to get
meaningful errors when running ser -cf ... , then getting unexpected
behaviour at runtime (a very good example for this are typed variables
vs. untyped ones or operators that try to guess the type and assume the
user made the right choice).
On Feb 20, 2009 at 11:15, Daniel-Constantin
Mierla <miconda(a)gmail.com> wrote:
I would suggest to convert numbers to strings in this case automatically. For
most people things get more confusing with the increasing amount of details
they have to remember about the configuration language. Hello Andrei,
On 02/20/2009 12:50 AM, Andrei Pelinescu-Onciul wrote:
Yes.
There are the following restriction:
- case labels must be static (no vars allowed)
- in the same switch you can have only one type of case labels: strings
or integers (1)
- the first case label sets the required type for all the others
(so if your first case label is a string => all the other must be
strings, if it's an integer all the other must be integers).
(1) - could be changed in some cases (e.g. string case with some int
label allowed, which could be automatically converted to string), but I
think it would too confusing and I disallowed it (in general having
mixed types in a switch() are 99% an error). [...]
script parsing: string switch support
that's great, thanks. From the next example, to understand the the case
can take expression that evaluates to static strings or integers?
This is similar to the difference between
if (method == INVITE) and if (method == "INVITE")
I guess most people won't be able to tell you the difference if you asked them.
I would not assume that mixed integers and strings are 99% errors, we don't
really know what people have in their configuration scripts and why, so this
assumption is IMHO not justified.
I tried //, but it produces an extra shift-reduce conflict in the
grammar (so it needs at least more testing).
I still think that using a different switch()
name for strings will be
less confusing (e.g. switch() for integers and match() for strings).
Yes, I like match for strings better too, especially if regular expression
matching is involved.
Any opinion on how to differentiate regular
expressions from strings?
Right now a '/' in front means a regular expression (but there's no way
to specify case insensitive match for example).
How about enclosing regular expressions in a pair of // like in awk or
perl. It would be possible to introduce a flag for case-insensitive matching, something
like:A
i/regex/
I was thinking more of /regex/i. Unfortunately for this we need a bigger
change in the grammar (I don't see an easier way right now). I agree
that it would be nicer, but I want to move to something else :-) (so if
there are some volunteers for adding the cfg.y support, I can then
easily enable the runtime code support for it, everything else is in
place).
For example:
case i/From/:
my two cents, Jan.
Andrei
3:54 p.m.
New subject: [SR-Dev] script parsing: string switch support
On Friday 20 February 2009, Andrei Pelinescu-Onciul wrote:
[..]
This would only make sense if we use match() for strings and switch()
for ints. Otherwise it would be too confusing.
Anyway I don't think the amount of details of the configuration language
is ever a problem, as long as one gets meaningful error messages when
checking the config (and before ser startup).
Hi Andrei,
the amount of detail in the config language is IMHO important. The developers
must document and test every single statement. Every user must read, learn
and memorize each statement too.
I regulary need to check the documentation for some special cases in the
config when i get asked for a review of some changes a co-worker did, because
he still feel not completely confortable after years of administrating SER*
systems. During all the time i spend on user channels i really rarely heard
the that our server is to slow (only when some real bottlenecks were
involved, like DB), the common complain is that the learning curve is too
steep. Perhaps i'm lazy, but i'd not say that everybody out there is it
too. ;-)
(1) -
could be changed in some cases (e.g. string case with some int
label allowed, which could be automatically converted to string), but I
think it would too confusing and I disallowed it (in general having
mixed types in a switch() are 99% an error).
I would suggest to convert numbers to strings in this case automatically.
For most people things get more confusing with the increasing amount of
details they have to remember about the configuration language. The other approaches trade-off less config details for
guessing what the
user intended, which IMO is much more dangerous. Is much better to get
meaningful errors when running ser -cf ... , then getting unexpected
behaviour at runtime (a very good example for this are typed variables
vs. untyped ones or operators that try to guess the type and assume the
user made the right choice).
I just checked in kamailio, we don't throw an error if one mix strings and
ints in a switch case. We also check for a correct type of an integer in a
mixed expression, e.g. if its a valid int value. I don't think that we
convert them implicitly, as many pseudo-variables hold internally both a
string and a integer value, so mixed expression will work just as intended in
most cases.
Cheers,
Henning
4:01 p.m.
New subject: [SR-Dev] script parsing: string switch support
On Feb 20, 2009 at 15:54, Henning Westerholt <henning.westerholt(a)1und1.de> wrote:
Sorry, but that's just broken (mixed expressions).
Andrei
On Friday 20 February 2009, Andrei Pelinescu-Onciul
wrote:
Good luck with runtime debugging then :-)
[..]
This would only make sense if we use match() for strings and switch()
for ints. Otherwise it would be too confusing.
Anyway I don't think the amount of details of the configuration language
is ever a problem, as long as one gets meaningful error messages when
checking the config (and before ser startup).
Hi Andrei,
the amount of detail in the config language is IMHO important. The developers
must document and test every single statement. Every user must read, learn
and memorize each statement too.
I regulary need to check the documentation for some special cases in the
config when i get asked for a review of some changes a co-worker did, because
he still feel not completely confortable after years of administrating SER*
systems. During all the time i spend on user channels i really rarely heard
the that our server is to slow (only when some real bottlenecks were
involved, like DB), the common complain is that the learning curve is too
steep. Perhaps i'm lazy, but i'd not say that everybody out there is it
too. ;-) (1) -
could be changed in some cases (e.g. string case with some int
label allowed, which could be automatically converted to string), but I
think it would too confusing and I disallowed it (in general having
mixed types in a switch() are 99% an error).
I would suggest to convert numbers to strings in this case automatically.
For most people things get more confusing with the increasing amount of
details they have to remember about the configuration language. The other approaches trade-off less config
details for guessing what the
user intended, which IMO is much more dangerous. Is much better to get
meaningful errors when running ser -cf ... , then getting unexpected
behaviour at runtime (a very good example for this are typed variables
vs. untyped ones or operators that try to guess the type and assume the
user made the right choice).
I just checked in kamailio, we don't throw an error if one mix strings and
ints in a switch case. We also check for a correct type of an integer in a
mixed expression, e.g. if its a valid int value. I don't think that we
convert them implicitly, as many pseudo-variables hold internally both a
string and a integer value, so mixed expression will work just as intended in
4:06 p.m.
New subject: [SR-Dev] script parsing: string switch support
On Friday 20 February 2009, Andrei Pelinescu-Onciul wrote:
Good luck with runtime debugging then :-)
Ok, perhaps we just trade this problem for another one.. ;-) Anyway, i'm
really curious about other opinions on this topic.
Sorry, but that's just broken (mixed expressions).
Yes, i also would not recommend it at all. I was even surprised that it
actually parse the configuration file..
Cheers,
Henning
This would only make sense if we use match() for
strings and switch()
for ints. Otherwise it would be too confusing.
Anyway I don't think the amount of details of the configuration
language is ever a problem, as long as one gets meaningful error
messages when checking the config (and before ser startup).
the amount of detail in the config language is IMHO important. The
developers must document and test every single statement. Every user must
read, learn and memorize each statement too.
I regulary need to check the documentation for some special cases in the
config when i get asked for a review of some changes a co-worker did,
because he still feel not completely confortable after years of
administrating SER* systems. During all the time i spend on user channels
i really rarely heard the that our server is to slow (only when some real
bottlenecks were involved, like DB), the common complain is that the
learning curve is too steep. Perhaps i'm lazy, but i'd not say that
everybody out there is it too. ;-) The other approaches trade-off less config details for
guessing what
the user intended, which IMO is much more dangerous. Is much better to
get meaningful errors when running ser -cf ... , then getting
unexpected behaviour at runtime (a very good example for this are typed
variables vs. untyped ones or operators that try to guess the type and
assume the user made the right choice).
I just checked in kamailio, we don't throw an error if one mix strings
and ints in a switch case. We also check for a correct type of an integer
in a mixed expression, e.g. if its a valid int value. I don't think that
we convert them implicitly, as many pseudo-variables hold internally both
a string and a integer value, so mixed expression will work just as
intended in
4:18 p.m.
New subject: [SR-Dev] script parsing: string switch support
On Feb 20, 2009 at 16:01, Andrei Pelinescu-Onciul <andrei(a)iptel.org> wrote:
On Feb 20, 2009 at 15:54, Henning Westerholt
<henning.westerholt(a)1und1.de> wrote:
Sorry, but that's just broken (mixed expressions).
I don't really understand this argument. Leaving performance and
optimizations aside, do you really think is better to guess what the
user might have wanted in ambiguous cases, rather then through an error
and point him to explain more clearly what he wants (e.g. use match()
instead of switch() for strings, or use typed variables)?
With the general approach advocated by some people here, a small error
when writing the script (e.g. forgetting some "") will be visible only at
runtime (and depending where that error is it could take weeks until
that branch of the config is reached and the error is triggered).
I think this is much worse then having to add a little more "details" to
the script (which BTW wouldn't make it any more difficult then any
common programming language).
I'd rather have to declare even variable types (e.g. int $a), rather
then debugging strange bugs in a script, because I used a var that
happens to get a string value at runtime.
In brief I much prefer adding to the script if this helps check its
correctness at sr -cf time, rather then trying to be excessively friendly
and leaving a lot of potential script bugs pass-through.
The ability to be able to tell that the script would behave correctly
(as his writer wanted it to) and eliminate ambiguous cases is more
important than trying to keep a very reduced script and guessing what
the writer really wanted.
Andrei
On Friday 20 February 2009, Andrei
Pelinescu-Onciul wrote:
Good luck with runtime debugging then :-)
[..]
Hi Andrei,
the amount of detail in the config language is IMHO important. The developers
must document and test every single statement. Every user must read, learn
and memorize each statement too.
I regulary need to check the documentation for some special cases in the
config when i get asked for a review of some changes a co-worker did, because
he still feel not completely confortable after years of administrating SER*
systems. During all the time i spend on user channels i really rarely heard
the that our server is to slow (only when some real bottlenecks were
involved, like DB), the common complain is that the learning curve is too
steep. Perhaps i'm lazy, but i'd not say that everybody out there is it
too. ;-) > (1) - could be changed in some cases (e.g.
string case with some int
> label allowed, which could be automatically converted to string), but I
> think it would too confusing and I disallowed it (in general having
> mixed types in a switch() are 99% an error).
I would suggest to convert numbers to strings in this case automatically.
For most people things get more confusing with the increasing amount of
details they have to remember about the configuration language.
This would only make sense if we use match() for strings and switch()
for ints. Otherwise it would be too confusing.
Anyway I don't think the amount of details of the configuration language
is ever a problem, as long as one gets meaningful error messages when
checking the config (and before ser startup). The other approaches trade-off less config
details for guessing what the
user intended, which IMO is much more dangerous. Is much better to get
meaningful errors when running ser -cf ... , then getting unexpected
behaviour at runtime (a very good example for this are typed variables
vs. untyped ones or operators that try to guess the type and assume the
user made the right choice).
I just checked in kamailio, we don't throw an error if one mix strings and
ints in a switch case. We also check for a correct type of an integer in a
mixed expression, e.g. if its a valid int value. I don't think that we
convert them implicitly, as many pseudo-variables hold internally both a
string and a integer value, so mixed expression will work just as intended in
24 Feb
24 Feb
11:06 a.m.
New subject: [SR-Dev] script parsing: string switch support
On Friday 20 February 2009, Andrei Pelinescu-Onciul wrote:
[..]
I don't really understand this argument. Leaving performance and
optimizations aside, do you really think is better to guess what the
user might have wanted in ambiguous cases, rather then through an error
and point him to explain more clearly what he wants (e.g. use match()
instead of switch() for strings, or use typed variables)?
I think that its important to not make our config script too much like a "real
programming language", with types and cast and this stuff. There is are
reasons that script languages like python or perl are now widely used instead
of e.g. C, even if their dynamic typed nature moves some error checks into
run time. The benefits (higher expressiveness that leads to more compact
code, fewer bugs because of automatic memory management etc..) outplay the
drawbacks, IMHO.
I just
checked in kamailio, we don't throw an error if one mix strings
and ints in a switch case. We also check for a correct type of an
integer in a mixed expression, e.g. if its a valid int value. I don't
think that we convert them implicitly, as many pseudo-variables hold
internally both a string and a integer value, so mixed expression will
work just as intended in
Sorry, but that's just broken (mixed expressions). With the general approach advocated by some people
here, a small error
when writing the script (e.g. forgetting some "") will be visible only at
runtime (and depending where that error is it could take weeks until
that branch of the config is reached and the error is triggered).
I think this is much worse then having to add a little more "details" to
the script (which BTW wouldn't make it any more difficult then any
common programming language).
Well, many people that uses our script language are not programmers. And even
experienced crypto gurus seems to have difficulties with the complexity that
common languages bring with it [1]. ;-)
I'd rather have to declare even variable types
(e.g. int $a), rather
then debugging strange bugs in a script, because I used a var that
happens to get a string value at runtime.
In brief I much prefer adding to the script if this helps check its
correctness at sr -cf time, rather then trying to be excessively friendly
and leaving a lot of potential script bugs pass-through.
The ability to be able to tell that the script would behave correctly
(as his writer wanted it to) and eliminate ambiguous cases is more
important than trying to keep a very reduced script and guessing what
the writer really wanted.
I've of course nothing general against eleminating abiguous cases, like in the
switch statement. If the user mix strings and int values in the cases, we
really should report an error.
Cheers,
Henning
[1] http://blog.fortify.com/blog/fortify/2009/02/20/SHA-3-Round-1
20 Feb
20 Feb
4:05 p.m.
New subject: [SR-Dev] script parsing: string switch support
On 02/20/2009 04:54 PM, Henning Westerholt wrote:
On Friday 20 February 2009, Andrei Pelinescu-Onciul
wrote:
this is because the most of PVs have the string value as
well.
However, I consider that misleading, although I worked a lot the switch.
It was planned to fix as the PV callbacks had a parameter for flags.
I would prefer single type case value, and report errors at startup - it
is easier to check and optimize. It is better to use a transformation to
convert the value to a specific type (e.g., {s.int}).
Cheers,
Daniel
[..]
This would only make sense if we use match() for strings and switch()
for ints. Otherwise it would be too confusing.
Anyway I don't think the amount of details of the configuration language
is ever a problem, as long as one gets meaningful error messages when
checking the config (and before ser startup).
Hi Andrei,
the amount of detail in the config language is IMHO important. The developers
must document and test every single statement. Every user must read, learn
and memorize each statement too.
I regulary need to check the documentation for some special cases in the
config when i get asked for a review of some changes a co-worker did, because
he still feel not completely confortable after years of administrating SER*
systems. During all the time i spend on user channels i really rarely heard
the that our server is to slow (only when some real bottlenecks were
involved, like DB), the common complain is that the learning curve is too
steep. Perhaps i'm lazy, but i'd not say that everybody out there is it
too. ;-)
(1) -
could be changed in some cases (e.g. string case with some int
label allowed, which could be automatically converted to string), but I
think it would too confusing and I disallowed it (in general having
mixed types in a switch() are 99% an error).
I would suggest to convert numbers to strings in this case
automatically.
For most people things get more confusing with the increasing amount of
details they have to remember about the configuration language.
The other approaches trade-off less config
details for guessing what the
user intended, which IMO is much more dangerous. Is much better to get
meaningful errors when running ser -cf ... , then getting unexpected
behaviour at runtime (a very good example for this are typed variables
vs. untyped ones or operators that try to guess the type and assume the
user made the right choice).
I just checked in kamailio, we don't throw an error if one mix strings and
ints in a switch case. We also check for a correct type of an integer in a
mixed expression, e.g. if its a valid int value. I don't think that we
convert them implicitly, as many pseudo-variables hold internally both a
string and a integer value, so mixed expression will work just as intended in
most cases.
Cheers,
Henning
_______________________________________________
sr-dev mailing list
sr-dev(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
--
Daniel-Constantin Mierla
http://www.asipto.com
4:11 p.m.
New subject: [SR-Dev] script parsing: string switch support
On 02/20/2009 05:05 PM, Daniel-Constantin Mierla wrote:
On 02/20/2009 04:54 PM, Henning Westerholt wrote:
... re-reading ... looks like half explained, so here is more ... the
flags parameter was intended to specify what type or value to get from
PV (int or str), so the PV callback function does not need to provide
the string representation if there is an int behind PV and int is
required for the operation.
Now there are some operations done for nothing, inherited because of PV
roots in xlog where everything needed to be string represented.
On Friday 20 February 2009, Andrei
Pelinescu-Onciul wrote:
this is because the most of PVs have the string value as well.
However, I consider that misleading, although I worked a lot the switch.
It was planned to fix as the PV callbacks had a parameter for flags.
[..]
Hi Andrei,
the amount of detail in the config language is IMHO important. The developers
must document and test every single statement. Every user must read, learn
and memorize each statement too.
I regulary need to check the documentation for some special cases in the
config when i get asked for a review of some changes a co-worker did, because
he still feel not completely confortable after years of administrating SER*
systems. During all the time i spend on user channels i really rarely heard
the that our server is to slow (only when some real bottlenecks were
involved, like DB), the common complain is that the learning curve is too
steep. Perhaps i'm lazy, but i'd not say that everybody out there is it
too. ;-)
> (1) - could be changed in some cases (e.g.
string case with some int
> label allowed, which could be automatically converted to string), but I
> think it would too confusing and I disallowed it (in general having
> mixed types in a switch() are 99% an error).
>
>
I would suggest to convert numbers to strings in this case automatically.
For most people things get more confusing with the increasing amount of
details they have to remember about the configuration language.
This would only make sense if we use match() for strings and switch()
for ints. Otherwise it would be too confusing.
Anyway I don't think the amount of details of the configuration language
is ever a problem, as long as one gets meaningful error messages when
checking the config (and before ser startup).
The other approaches trade-off less config
details for guessing what the
user intended, which IMO is much more dangerous. Is much better to get
meaningful errors when running ser -cf ... , then getting unexpected
behaviour at runtime (a very good example for this are typed variables
vs. untyped ones or operators that try to guess the type and assume the
user made the right choice).
I just checked in kamailio, we don't throw an error if one mix strings
and
ints in a switch case.
I would prefer single type case value, and report
errors at startup - it
is easier to check and optimize. It is better to use a transformation to
convert the value to a specific type (e.g., {s.int}).
I mean, use transformation or equivalent to the variable used in
'switch(var)'.
Cheers,
Daniel
Cheers,
Daniel
--
Daniel-Constantin Mierla
http://www.asipto.com
We also check for a correct type of an integer
in a
mixed expression, e.g. if its a valid int value. I don't think that we
convert them implicitly, as many pseudo-variables hold internally both a
string and a integer value, so mixed expression will work just as intended in
most cases.
Cheers,
Henning
_______________________________________________
sr-dev mailing list
sr-dev(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
23 Feb
23 Feb
5:07 p.m.
New subject: [SR-Dev] script parsing: string switch support
On 20-02 14:25, Andrei Pelinescu-Onciul wrote:
On Feb 20, 2009 at 14:03, Jan Janak
<jan(a)iptel.org> wrote:
OK, so if the script writer writes something like:
switch((a)from.uri.user) {
case "abc": ...
case 100: ...
case "foo" ..
}
This is obviously a string based switch. What would you want to do with the
second (integer) case? Report an error? Or convert it to string, making it
equivalent to:
switch($foo) {
case "abc": ...
case "1": ...
case "foo" ..
}
This is the case we are talking about, right?
Jan.
On 20-02 12:22, Andrei Pelinescu-Onciul wrote:
This would only make sense if we use match() for strings and switch()
for ints. Otherwise it would be too confusing.
Anyway I don't think the amount of details of the configuration language
is ever a problem, as long as one gets meaningful error messages when
checking the config (and before ser startup).
The other approaches trade-off less config details for guessing what the
user intended, which IMO is much more dangerous. Is much better to get
meaningful errors when running ser -cf ... , then getting unexpected
behaviour at runtime (a very good example for this are typed variables
vs. untyped ones or operators that try to guess the type and assume the
user made the right choice). On Feb 20, 2009 at 11:15, Daniel-Constantin
Mierla <miconda(a)gmail.com> wrote:
I would suggest to convert numbers to strings in this case automatically. For
most people things get more confusing with the increasing amount of details
they have to remember about the configuration language. Hello Andrei,
On 02/20/2009 12:50 AM, Andrei Pelinescu-Onciul wrote:
>[...]
>
>script parsing: string switch support
>
that's great, thanks. From the next example, to understand the the case
can take expression that evaluates to static strings or integers?
Yes.
There are the following restriction:
- case labels must be static (no vars allowed)
- in the same switch you can have only one type of case labels: strings
or integers (1)
- the first case label sets the required type for all the others
(so if your first case label is a string => all the other must be
strings, if it's an integer all the other must be integers).
(1) - could be changed in some cases (e.g. string case with some int
label allowed, which could be automatically converted to string), but I
think it would too confusing and I disallowed it (in general having
mixed types in a switch() are 99% an error). 
8:19 p.m.
New subject: [SR-Dev] script parsing: string switch support
Jan Janak writes:
OK, so if the script writer writes something like:
switch((a)from.uri.user) {
case "abc": ...
case 100: ...
case "foo" ..
}
i my opinion it is unnecessary to allow such a mix of case label types.
reporting an error is an appropriate thing to do.
-- juha
10:24 p.m.
New subject: [SR-Dev] script parsing: string switch support
On 23-02 21:19, Juha Heinanen wrote:
Jan Janak writes:
Yeah, I admit that I might have been wrong, reporting an error seems
appropriate. Andrei's last reply on this thread convinced me.
Jan.
OK, so if the script writer writes something
like:
switch((a)from.uri.user) {
case "abc": ...
case 100: ...
case "foo" ..
}
i my opinion it is unnecessary to allow such a mix of case label types.
reporting an error is an appropriate thing to do.
5:12 p.m.
New subject: [SR-Dev] script parsing: string switch support
On 20-02 14:25, Andrei Pelinescu-Onciul wrote:
On Feb 20, 2009 at 14:03, Jan Janak
<jan(a)iptel.org> wrote:
I like the idea of using match for strings and switch for integers, somehow
using match for strings seams more logical to me, but I realize that this is
just a personal preference.
Jan.
On 20-02 12:22, Andrei Pelinescu-Onciul wrote:
This would only make sense if we use match() for strings and switch()
for ints. Otherwise it would be too confusing. On Feb 20, 2009 at 11:15, Daniel-Constantin
Mierla <miconda(a)gmail.com> wrote:
I would suggest to convert numbers to strings in this case automatically. For
most people things get more confusing with the increasing amount of details
they have to remember about the configuration language. Hello Andrei,
On 02/20/2009 12:50 AM, Andrei Pelinescu-Onciul wrote:
>[...]
>
>script parsing: string switch support
>
that's great, thanks. From the next example, to understand the the case
can take expression that evaluates to static strings or integers?
Yes.
There are the following restriction:
- case labels must be static (no vars allowed)
- in the same switch you can have only one type of case labels: strings
or integers (1)
- the first case label sets the required type for all the others
(so if your first case label is a string => all the other must be
strings, if it's an integer all the other must be integers).
(1) - could be changed in some cases (e.g. string case with some int
label allowed, which could be automatically converted to string), but I
think it would too confusing and I disallowed it (in general having
mixed types in a switch() are 99% an error).
20 Feb
20 Feb
4:20 p.m.
New subject: [SR-Dev] script parsing: string switch support
On 02/20/2009 01:22 PM, Andrei Pelinescu-Onciul wrote:
Do you mean that the expression has to evaluate to int? This has to be
relaxed for strings and NULL for PVs. I will have a look latter.
Cheers,
Daniel
On Feb 20, 2009 at 11:15, Daniel-Constantin Mierla
<miconda(a)gmail.com> wrote:
ok.
Hello Andrei,
On 02/20/2009 12:50 AM, Andrei Pelinescu-Onciul wrote:
Yes.
There are the following restriction:
- case labels must be static (no vars allowed)
- in the same switch you can have only one type of case labels: strings
or integers (1)
- the first case label sets the required type for all the others
(so if your first case label is a string => all the other must be
strings, if it's an integer all the other must be integers).
[...]
script parsing: string switch support
that's great, thanks. From the next example, to understand the the case
can take expression that evaluates to static strings or integers?
(1) - could be changed in some cases (e.g. string case
with some int
label allowed, which could be automatically converted to string), but I
think it would too confusing and I disallowed it (in general having
mixed types in a switch() are 99% an error).
I still think that using a different switch() name for
strings will be
less confusing (e.g. switch() for integers and match() for strings).
I prefer single type case value instead of mixed (as it is in kamailio
now, but somehow useless and confusing, I doubt someone is using it),
but not two different statements. I think switch as it is now is just fine.
Any opinion on how to differentiate regular
expressions from strings?
Right now a '/' in front means a regular expression (but there's no way
to specify case insensitive match for example).
What about '~' which is the one used in IF.
Now, with while and switch in there I can work to
get most of my configs
working with sip-router.
Warning: the while works only with integers :-)
Andrei
_______________________________________________
sr-dev mailing list
sr-dev(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
--
Daniel-Constantin Mierla
http://www.asipto.com
8:39 p.m.
New subject: [SR-Dev] script parsing: string switch support
Andrei Pelinescu-Onciul writes:
There are the following restriction:
- case labels must be static (no vars allowed)
- in the same switch you can have only one type of case labels: strings
or integers (1)
- the first case label sets the required type for all the others
(so if your first case label is a string => all the other must be
strings, if it's an integer all the other must be integers).
andrei,
thanks for the above implementation. the restrictions are fine with me,
-- juha
5549
days inactive
5554
days old
17 comments
5 participants
participants (5)
-
Andrei Pelinescu-Onciul -
Daniel-Constantin Mierla -
Henning Westerholt -
Jan Janak -
jh＠tutpro.com