[asterisk-bugs] [Asterisk 0010549]: "Set" application silently changed in trunk to no longer support multiple assignments

[noreply at bugs.digium.com]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=10549 
====================================================================== 
Reported By:                stevedavies
Assigned To:                Corydon76
====================================================================== 
Project:                    Asterisk
Issue ID:                   10549
Category:                   Addons/General
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     closed
Asterisk Version:            SVN 
SVN Branch (only for SVN checkouts, not tarball releases): N/A  
SVN Revision (number only!): 80453 
Disclaimer on File?:        N/A 
Request Review:              
Resolution:                 fixed
Fixed in Version:           
====================================================================== 
Date Submitted:             08-24-2007 05:33 CDT
Last Modified:              08-26-2007 01:43 CDT
====================================================================== 
Summary:                    "Set" application silently changed in trunk to no
longer support multiple assignments
Description: 
On Jul 23rd, Tilghman merged the dialplan_aesthetics branch.  (pbx.c went
from rev 76555 to rev 76703.

His comment suggests this merge should be transparent except for no longer
supporting the App,arg|arg format.

In fact the merge also changes the Set application to no longer support
multiple assignments.

So code that looks like so "Set(var1=value1|var2=value2) now suddenly
assigns value1|var2=value2 into var1, whereas before it did the two
assignments.

Multiple assignments is still sort-of documented in the show application
output for Set in trunk.  And it certainly works and is documented in 1.4,
and has never been marked or documented as deprecated.

Looks like support for the "g" option is also removed.

Here is the relevant change:

@@ -5867,35 +5871,17 @@
 int pbx_builtin_setvar(struct ast_channel *chan, void *data)
 {
        char *name, *value, *mydata;
-       int argc;
-       char *argv[24];         /* this will only support a maximum of 24
variables being set in a single operation */
-       int global = 0;
-       int x;
 
        if (ast_strlen_zero(data)) {
-               ast_log(LOG_WARNING, "Set requires at least one variable
name/value pair.\n");
+               ast_log(LOG_WARNING, "Set requires one variable name/value
pair.\n");
                return 0;
        }
 
        mydata = ast_strdupa(data);
-       argc = ast_app_separate_args(mydata, '|', argv, sizeof(argv) /
sizeof(argv[0]));
+       name = strsep(&mydata, "=");
+       value = mydata;
 
-       /* check for a trailing flags argument */
-       if ((argc > 1) && !strchr(argv[argc-1], '=')) {
-               argc--;
-               if (strchr(argv[argc], 'g'))
-                       global = 1;
-       }
-
-       for (x = 0; x < argc; x++) {
-               name = argv[x];
-               if ((value = strchr(name, '='))) {
-                       *value++ = '\0';
-                       pbx_builtin_setvar_helper((global) ? NULL : chan,
name, value);
-               } else
-                       ast_log(LOG_WARNING, "Ignoring entry '%s' with no
= (and not last 'options' entry)\n", name);
-       }
-
+       pbx_builtin_setvar_helper(chan, name, value);
        return(0);
 }
 
====================================================================== 

---------------------------------------------------------------------- 
 Corydon76 - 08-26-07 01:43  
---------------------------------------------------------------------- 
stevedavies:  We're specifically trying to make the Set application behave
correctly when you retrieve a value from a database that contains a comma. 
With Set taking multiple arguments, it behaves incorrectly.  Having users
separate their Set name/value pairs into separate lines is not a big
change, while making database integration easier.  That's why we've chosen
to go down this path.

I realize that this causes an issue with some dialplans, including some of
my own, but I think this also is the right way to go to allow us to create
even more complex dialplans in the future, without making the syntax
difficult to read. 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
08-26-07 01:43  Corydon76      Note Added: 0069435                          
======================================================================