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

Asterisk Bug Tracker noreply at bugs.digium.com
Sun Oct 26 15:12:46 CDT 2008


A NOTE has been added to this issue. 
====================================================================== 
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 15:12 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.

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

---------------------------------------------------------------------- 
 (0094292) svnbot (reporter) - 2008-10-26 15:12
 http://bugs.digium.com/view.php?id=13787#c94292 
---------------------------------------------------------------------- 
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 http://bugs.digium.com/view.php?id=13787)
Reported by: meitinger

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=152059 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2008-10-26 15:12 svnbot         Note Added: 0094292                          
======================================================================




More information about the asterisk-bugs mailing list