[asterisk-bugs] [Asterisk 0014614]: [patch] func_odbc's OPT_ESCAPECOMMA's is undone by second ast_app_separate_args call when using Set(ARRAY...)
Asterisk Bug Tracker
noreply at bugs.digium.com
Mon Mar 9 03:20:42 CDT 2009
A NOTE has been added to this issue.
======================================================================
http://bugs.digium.com/view.php?id=14614
======================================================================
Reported By: wdoekes
Assigned To: tilghman
======================================================================
Project: Asterisk
Issue ID: 14614
Category: Functions/func_odbc
Reproducibility: always
Severity: major
Priority: normal
Status: assigned
Asterisk Version: SVN
Regression: No
SVN Branch (only for SVN checkouts, not tarball releases): 1.4
SVN Revision (number only!): 180528
Request Review:
======================================================================
Date Submitted: 2009-03-06 07:20 CST
Last Modified: 2009-03-09 03:20 CDT
======================================================================
Summary: [patch] func_odbc's OPT_ESCAPECOMMA's is undone by
second ast_app_separate_args call when using Set(ARRAY...)
Description:
When returning more than one column with func_odbc custom functions, the
comma's that should separate the columns are not escaped. This happens when
setting the variables through the ARRAY function:
=== Example ===
(extensions.conf)
exten => _X.,1,Set(ARRAY(a|b)=${MY_ODBC_FUNC()})
(func_odbc.conf)
read=SELECT 'column, with comma', 1
The above results in:
${a} == "column", ${b} == ", with comma"
instead of:
${a} == "column, with comma", ${b} == 1
=== Cause ===
ast_app_separate_args is called twice on
"""ARRAY(a|b)=value\, with comma,1"""
once in pbx_builtin_setvar() (pbx.c) and once in array() (func_strings.c)
(through AST_NONSTANDARD_APP_ARGS).
The first one removes all the backslashes but doesn't split the arguments
because the delimiter is '|'.
Then you have """value, with comma,1""" which is split in three parts.
=== Problem ===
The problem lies in the double unescaping of the backslash and has nothing
to do with func_odbc per se. To set multiple variables at once, one must
do:
exten => _X.,1,Set(ARRAY(a|b|c)=1\\|2\\|3)
(double escape)
=== Solution ===
I don't know if the double unescaping is intended (according to my
O'Reilly book for 1.4 it isn't). When writing a Set statement without odbc
functions, one can double escape the comma, or resort to multiple Set
statements.
When using func_odbc, double-escaping the comma's could be a workaround.
See the attached patch.
======================================================================
----------------------------------------------------------------------
(0101354) wdoekes (reporter) - 2009-03-09 03:20
http://bugs.digium.com/view.php?id=14614#c101354
----------------------------------------------------------------------
Well, yes. And here's why:
Set("SIP/1000-0820a2c0", "ARRAY(a|b)=bs-cm \\\\\\\, cm \\\, bs \\\\
eol,1") in new stack
NoOp("SIP/1000-0820a2c0", "a = bs-cm \, cm , bs \ eol") in new stack
NoOp("SIP/1000-0820a2c0", "b = 1") in new stack
Set("SIP/1000-0820a2c0", "a=bs-cm \\\\\\\, cm \\\, bs \\\\ eol") in new
stack
NoOp("SIP/1000-0820a2c0", "a = bs-cm \\\, cm \, bs \\ eol") in new stack
If I set "readarray=yes" for both Set(ARRAY(a,b)=${MY_TWO_COLUMN_FUNC()})
Set(a=${MY_ONE_COLUMN_FUNC()}) then the latter one will get unescaped only
once.
Preconditions for the above:
(1) It uses my patch and both MY*FUNC() obdc functions use
"readarray=yes". I "fixed" my patch by adding a second """buf[buflen++] =
'\\';""" in the readarray case. The patch was broken in that it only did a
partial double escape.
(2) extensions.conf looks like this:
exten => _XXX.,n,Set(ARRAY(a,b)=${MY_TWO_COLUMN_FUNC()})
exten => _XXX.,n,NoOp(a = ${a})
exten => _XXX.,n,NoOp(b = ${b})
exten => _XXX.,n,Set(a=${MY_ONE_COLUMN_FUNC()})
exten => _XXX.,n,NoOp(a = ${a})
(3) The first column fetched from the database contains "bs-cm \, cm , bs
\ eol"
If I set "readarray=no" in MY_ONE_COLUMN_FUNC, then the results turn out
as wanted. As far as I could tell, the second unescape was caused by the
ARRAY() function and that one is not called in the single column case.
(Unless it is strictly forbidden to NOT use ARRAY when fetching odbc
data...)
Issue History
Date Modified Username Field Change
======================================================================
2009-03-09 03:20 wdoekes Note Added: 0101354
======================================================================
More information about the asterisk-bugs
mailing list