在字符串数组中搜索字符串的函数

Shivalnu 发表于 Dev

Shivalnu

我正在尝试编写一个函数，该函数在字符串数组中搜索字符串的唯一部分（最多两个字符）。虽然strstr和strchr不能正常工作，但由于某种原因使我的程序崩溃。因此，我不得不尝试创建类似于其功能的东西。

我的问题是：
为什么strstr无法正常工作（类似strstr(lex[j],word)），我在这里做错了什么？

这是在字符串数组中搜索两个唯一字符的函数的代码：

void convert(char word[])
{
    int i;

    for (i = 0 ; i <= strlen(word) ; i++)
    {
        if(word[i] >= 65 && word[i] <= 90)
        {
            word[i] = word[i]+32;
        }
    }
}


int  twochar(char lex[50][50],char word[], int size,char temp[3])
{
    int i,j,k,count,totlen;
    convert(word);

    for (i = 0 ; i < strlen(word) - 1 ; i++)
    {
        count = 0;
        totlen = 0;
        for(j = 0; j<size; j++)
        {
            convert(lex[j]);
            totlen += strlen(lex[j]) - 1;
            for(k = 0 ; k < strlen(lex[j]) - 1 ; k++)
            {
                if (word[i] != lex[j][k] || word[i+1] != lex[j][k + 1])
                {
                    count++;
                }
            }
        }
        if(count =  = totlen)
        {
            temp[0] = word[i];
            temp[1] = word[i+1];
        }
    }
}



int main(int argc, char *argv[])
{
    char lex[50][50] =  {"word1","word2","word3","word4" }, word[] = "test";
    char p[3];

    twochar(lex,word,4,p);
    printf("%c%c\n",p[0],p[1]);
    return 0;
}

用户名

这行：

for(k=0;k<strlen(lex[j])-1;k++)

是问题。

strlen(lex[0]) is 0
strlen(lex[0])-1 is -1 (0xFFFFFFFF in a 32 bit system)
k starts at 0 and is incremented until it is equal to 0xFFFFFFFF

当然，当k = 50时，k超过lex [0]的范围。

结果是导致seg故障事件的不确定行为

为了确定以上所有内容，我通过gcc使用-ggdb参数编译/链接了该程序。

然后我通过'gdb theprogram'运行了程序

within gdb I entered
br main <-- break point set
run
c <-- continue
the program then crashed with a seg fault event
then I entered
bt  <-- back trace
the bt showed me this line: 'if(word[i]!=lex[j][k] || word[i+1]!=lex[j] [k+1])'
Then I entered
p k <-- print variable k
=6832   (which is WAY out of bounds)

then I entered
run
y
br theprogram.c:41    (the line number from above) <-- set another break epoint
c
the program stopped at line 41
p j
=0  ( this was the gdb response )
p k 
= 0
p i
= 0

a little thinking, 
stepping though that inner loop using 'n' <-- next
and playing on gdb 
indicated that the problem was in line 42
and resulted in revealing the root of the problem