No subject

h sensitive to case and insensitive to case has got to be unexpected.  The =
proposal is to make it consistent - which probably means matching the docum=
entation on wiki.asterisk.org and making it case sensitive.  If done in 1.8=
, this needs to be noted in the UPGRADE file.

At the minimum, the would entail making the code in ast_str_retrieve_variab=
le should be made to be case sensitive:

{noformat}
=09/* if not found, look into chanvars or global vars */
=09for (i =3D 0; s =3D=3D &not_found && i < ARRAY_LEN(places); i++) {
=09=09struct ast_var_t *variables;
=09=09if (!places[i])
=09=09=09continue;
=09=09if (places[i] =3D=3D &globals)
=09=09=09ast_rwlock_rdlock(&globalslock);
=09=09AST_LIST_TRAVERSE(places[i], variables, entries) {
=09=09=09if (!strcasecmp(ast_var_name(variables), var)) {
=09=09=09=09s =3D ast_var_value(variables);
=09=09=09=09break;
=09=09=09}
=09=09}
=09=09if (places[i] =3D=3D &globals)
=09=09=09ast_rwlock_unlock(&globalslock);
=09}
{noformat}

There are potentially other areas where variables are evaluated however, an=
d all of those should be checked.


> Variables evaluated in dialplan are case insensitive, whereas channel var=
iables/system variables are not
> -------------------------------------------------------------------------=
-------------------------------
>
>                 Key: ASTERISK-20163
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-201=
63
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>            Reporter: Matt Jordan
>
> We were all a little taken aback by this one.
> Variables are documented on wiki.asterisk.org as being case sensitive.  S=
ome ancient documentation on voip-info makes the following note:
> "A variable name may be any alphanumeric string beginning with a letter. =
User-defined variable names are not case sensitive =E2=80=94 ${FOO} and ${F=
oo} refer to the same variable =E2=80=94 but Asterisk-defined variables are=
 case-sensitive =E2=80=94 ${EXTEN} works, but ${exten} doesn't."
> That seems... odd?  And yet, it is somewhat accidentally correct, per the=
 current implementation.  Consider a user defined variable "FOO".  Evaluati=
ng ${Foo} will yield the same value as evaluating ${FOO}.  So will ${FoO}. =
 This works for both channel variables, as well as global variables.
> On the other hand, if that variable is something known to an application =
or is evaluated outside of dialplan execution, then that variable is treate=
d as case sensitive.  So if a user sets variable ${MiXMONITOR_FILENAME}, th=
e MixMonitor application will not receive the intended value, as it evaluat=
es (case sensitive) variable ${MIXMONITOR_FILENAME}.  If a user later check=
s variable ${MIXMONITOR_FILENAME} in the dialplan, it will evaluate to the =
same variable name as ${MiXMONITOR_FILENAME}.
> From the perspective of the user, the fact that variables are evaluated b=
oth sensitive to case and insensitive to case has got to be unexpected.  Th=
e proposal is to make it consistent - which probably means matching the doc=
umentation on wiki.asterisk.org and making it case sensitive.  If done in 1=
.8, this needs to be noted in the UPGRADE file.
> At the minimum, the would entail making the code in ast_str_retrieve_vari=
able should be made to be case sensitive:
> {noformat}
> =09/* if not found, look into chanvars or global vars */
> =09for (i =3D 0; s =3D=3D &not_found && i < ARRAY_LEN(places); i++) {
> =09=09struct ast_var_t *variables;
> =09=09if (!places[i])
> =09=09=09continue;
> =09=09if (places[i] =3D=3D &globals)
> =09=09=09ast_rwlock_rdlock(&globalslock);
> =09=09AST_LIST_TRAVERSE(places[i], variables, entries) {
> =09=09=09if (!strcasecmp(ast_var_name(variables), var)) {
> =09=09=09=09s =3D ast_var_value(variables);
> =09=09=09=09break;
> =09=09=09}
> =09=09}
> =09=09if (places[i] =3D=3D &globals)
> =09=09=09ast_rwlock_unlock(&globalslock);
> =09}
> {noformat}
> There are potentially other areas where variables are evaluated however, =
and all of those should be checked.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira