Summary:ASTERISK-10807: Wrong parsing of application arguments Mysql Fetch
Reporter:Egbert Groot (wegbert)Labels:
Date Opened:2007-11-21 18:43:09.000-0600Date Closed:2007-12-12 11:13:46.000-0600
Versions:Frequency of
Environment:Attachments:( 0) 11343.patch
( 1) 11343v2.patch
Description:In function aMYSQL_fetch(struct ast_channel *chan, char *data),
after calling  AST_NONSTANDARD_APP_ARGS(args, data, ' ');
in the loop to fetch resultfields,
s5 = strsep(&datatmp, " ");  is not working.

- It can only find one variable
- It finds really the first argument, instead from starting of with the fourth.

My work around solutions involves copying 'data' to 'datatmp' (before calling AST_NONSTANDARD_APP_ARGS), and shifting of the first three arguments by calling
strsep(&datatmp, " ");  three times:

strsep(&datatmp, " ");
strsep(&datatmp, " ");
strsep(&datatmp, " ");

and then using  s5 = strsep(&datatmp, " "); in the field retrieval loop.


Debian 4.0 Linux vw8 2.6.18-5-686 #1 SMP Wed Oct 3 00:12:50 UTC 2007 i686 GNU/Linux
Comments:By: Mark Michelson (mmichelson) 2007-12-03 16:23:13.000-0600

After looking at that code for a long while, I realized that it was bizarre and possibly hazardous since it changes the input string. I have created a patch for this so that a local copy of the string is created instead, similar to what you have done in your workaround, but I decided against the calls to strsep in favor of adding a new AST_APP_ARG to the mix.

Give the patch a try and report if it fixes the problem. Thanks for bringing this issue to our attention!

By: Mark Michelson (mmichelson) 2007-12-04 11:37:12.000-0600

I realize I made a slight mistake in my patch, so I am uploading a corrected version. It's called 11343v2.patch

By: Digium Subversion (svnbot) 2007-12-12 11:13:46.000-0600

Repository: asterisk-addons
Revision: 496

U   trunk/app_addon_sql_mysql.c

r496 | mmichelson | 2007-12-12 11:13:43 -0600 (Wed, 12 Dec 2007) | 8 lines

The logic for parsing arguments in the MYSQL fetch function was incorrect.
Instead of starting at the fourth application argument, we were looping beginning
at the first. In addition to this change, I have changed the logic slightly so that
a local copy of the argument string is made instead of directly modifying the input data.

(closes issue ASTERISK-10807, reported by wegbert, patched by me)