Summary: | ASTERISK-12969: KEYPADHASH returns incorrect values | ||
Reporter: | Manuel Meitinger (meitinger) | Labels: | |
Date Opened: | 2008-10-26 11:40:30 | Date Closed: | 2008-10-26 15:12:48 |
Priority: | Minor | Regression? | No |
Status: | Closed/Complete | Components: | Functions/func_strings |
Versions: | Frequency of Occurrence | ||
Related Issues: | |||
Environment: | Attachments: | ||
Description: | I don't know how others ever managed to get KEYPADHASH working properly, but it should be impossible. The input string is traversed and each char is checked with strchr in an if-elseif-elseif-...-else fashion, checking for the null-terminator at the final else (and breaking the loop if it is encountered). However, if I may quote the manpage of strchr: "The terminating null character is considered to be part of the string; therefore if c is `\0', the functions locate the terminating `\0'." So once the null-terminator is encountered, the first strchr (which checks for key #2) always matches, so if one executed e.g. ${KEYPADHASH(test)} the returned value is 83782... followed by whatever is behind the null-terminator until the length of the output buffer is reached. Usually this is 22222222222... because more '\0' are encountered. Of course, this can easily be fixed. Just move the null-terminator-check from the final else to the first if. | ||
Comments: | By: Digium Subversion (svnbot) 2008-10-26 15:12:46 Repository: asterisk Revision: 152059 U branches/1.4/funcs/func_strings.c ------------------------------------------------------------------------ r152059 | seanbright | 2008-10-26 15:12:45 -0500 (Sun, 26 Oct 2008) | 7 lines Since passing \0 as the second argument to strchr is valid (and will match the trailing \0 of a string) we need to check that first, otherwise we end up with incorrect results. Fix suggested by reporter. (closes issue ASTERISK-12969) Reported by: meitinger ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=152059 |