[asterisk-bugs] [Asterisk 0013787]: KEYPADHASH returns incorrect values

[Asterisk Bug Tracker]

The following issue has been SUBMITTED. 
====================================================================== 
http://bugs.digium.com/view.php?id=13787 
====================================================================== 
Reported By:                meitinger
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   13787
Category:                   Functions/func_strings
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     new
Asterisk Version:           1.4.22 
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Disclaimer on File?:        N/A 
Request Review:              
====================================================================== 
Date Submitted:             2008-10-26 11:40 CDT
Last Modified:              2008-10-26 11:40 CDT
====================================================================== 
Summary:                    KEYPADHASH returns incorrect values
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 http://bugs.digium.com/view.php?id=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.

====================================================================== 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2008-10-26 11:40 meitinger      Asterisk Version          => 1.4.22          
2008-10-26 11:40 meitinger      SVN Branch (only for SVN checkouts, not tarball
releases) => N/A             
======================================================================