[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]

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:                     ready for testing
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-10 08:24 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.
====================================================================== 

---------------------------------------------------------------------- 
 (0101458) wdoekes (reporter) - 2009-03-10 08:24
 http://bugs.digium.com/view.php?id=14614#c101458 
---------------------------------------------------------------------- 
I can agree that an extra temporary option is not the way to go. This
~ODBCVALUES~ workaround does not look like the cleanest of solutions, but I
can live with it.

I've changed a couple of things:
- added escaping of double quotes and pipes
- removed some unecessary assignments

I'm not a 100% sure on whether your strecmp() is correct, but my testcase
passes:
  source_data = """bs-cm \, cm , \" bs \ pp | eol"""", """1"""
  strecmp(
    """bs-cm \\\, cm \, \\\" bs \\ pp \| eol\",1""",
    """bs-cm \, cm , \" bs \ pp | eol",1"""
  ) == 0

If I understand correctly, things will only go wrong if you do an ODBC
read and then later use ARRAY (without ODBC) with a string that looks very
much like an unescaped version of the previously returned values -- which
in turn is highly unlikely. Right? 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-03-10 08:24 wdoekes        Note Added: 0101458                          
======================================================================