strcpy当初没有考虑到的地方

strcpy当初没有考虑到的地方

原贴地址:
http://eparg.spaces.live.com/blog/cns!59BFC22C0E7E1A76!1498.entry
原贴时间:
2006-08-16
原贴作者:
eparg
 

当年的讨论在:

http://eparg.spaces.live.com/blog/cns!59BFC22C0E7E1A76!533.entry

http://eparg.spaces.live.com/blog/cns!59BFC22C0E7E1A76!875.entry

最开始考虑strcpy的性能的时候,只考虑了要4bytes一起拷贝。但是忽略了一个关键问题,就是如何判断字符串的结束。由于字符串可以从4bytes中任意一个byte结束,所以需要判断是否有任何一个byte为0。
如果对一个4bytes拆分成4个byte分别判断,那4bytes一起拷贝节省下拉性能立刻浪费掉了。今天看到Newer2k的回复,才重新开始考虑这个问题。
拿到C++的strcpy函数一看,源代码如下:

mov     edi,[esp+8]         ; edi points to dest string
 
copy_start::
       mov     ecx,[esp+0ch]       ; ecx -> sorc string
       test    ecx,3               ; test if string is aligned on 32 bits
       je      short main_loop_entrance
src_misaligned:                     ; simple byte loop until string is aligned
       mov     dl,byte ptr [ecx]
       add     ecx,1
       test    dl,dl
       je      short byte_0
       mov     [edi],dl
       add     edi,1
       test    ecx,3
       jne     short src_misaligned
       jmp     short main_loop_entrance
main_loop:                          ; edx contains first dword of sorc string
       mov     [edi],edx           ; store one more dword
       add     edi,4               ; kick dest pointer
main_loop_entrance:
       mov     edx,7efefeffh
       mov     eax,dword ptr [ecx] ; read 4 bytes
       add     edx,eax                                  
       xor     eax,-1
       xor     eax,edx
       mov     edx,[ecx]           ; it's in cache now
       add     ecx,4               ; kick dest pointer
       test    eax,81010100h
       je      short main_loop
       ; found zero byte in the loop
; main_loop_end:
       test    dl,dl               ; is it byte 0
       je      short byte_0
       test    dh,dh               ; is it byte 1
       je      short byte_1
       test    edx,00ff0000h       ; is it byte 2
       je      short byte_2
       test    edx,0ff000000h      ; is it byte 3
       je      short byte_3
       jmp     short main_loop     ; taken if bits 24-30 are clear and bit
                                   ; 31 is set
byte_3:
       mov     [edi],edx
       mov     eax,[esp+8]         ; return in eax pointer to dest string
       pop     edi
       ret
byte_2:
       mov     [edi],dx
       mov     eax,[esp+8]         ; return in eax pointer to dest string
       mov     byte ptr [edi+2],0
       pop     edi
       ret
byte_1:
       mov     [edi],dx
       mov     eax,[esp+8]         ; return in eax pointer to dest string
       pop     edi
       ret
byte_0:
       mov     [edi],dl
       mov     eax,[esp+8]         ; return in eax pointer to dest string
       pop     edi
       ret
 
这里对一个DWORD (EAX)的判断方法是:
 
1. 对EAX+0x7efefeff
2. 对EAX取反
3. 把1和2的结果作XOR,然后跟0x81010100h作test运算
 
研究了好久,理解如下:
 
问题的关键点在于,当且仅当EAX四个byte都不为0的时候,运算结果会是下面的pattern:

0??? ???0 ???? ???0 ???? ???0 ???? ????
 
分别解释如下:
 
如果第一个byte为0, 考虑第二个byte的最后一个bit。不管这个bit是0还是1,计算公式是:
(x+0) XOR (!x) =x xor !x=0

如果第一个byte不为0,肯定产生进位,考虑第二个byte的最后一个bit。不管这个bit是0还是1,计算公式是:
(x+1)XOR(!x)=!x xor !x=1
 
这就是上面0??? ???0 ???? ???0 ???? ???0 ???? ????第二个byte的第一个bit是0的来历
 
同理,第二,三,四个byte中的的第一个bit的0也是在前面所有的byte都不为0的时候才会出现,否则就会出现至少一个1
 
最后再来看最一个byte的最高位。根据前面的分析,我们已经可以确保前面三个byte为0的pattern。所以我们只需要考虑前面三个byte都不是0,然后检测最后一个byte是否为0的情况。这里分成三种情况来考虑最高一个bit的情况:
 
1) 最高byte为0
由于前面三个byte都不是0,所以相加后最高byte肯定拿到一个进位,所以最高byte的加法变成了跟7f相加。所以公式:
(0+0) XOR (!0) =1
 
2) 最高byte不为0,最高bit为0。这种情况下跟7f相加,相加结果最高bit肯定会变成1:
1 XOR (!0) =0
 
3) 最高byte不为0,最高bit为1。这种情况下跟7f相加,不管相加后最高为是0还是1,都有:
1 XOR (!1) =0
0 XOR (!1) =0
 
所以,如果EAX最高byte为0,结果的最高bit为1. 如果EAX最高byte不为0,结果最高的bit为0
 
综上,如果所有四个byte都不为0,最后得到的pattern是:
0??? ???0 ???? ???0 ???? ???0 ???? ????
 
于是我们可以拿结果跟0x81010100 作TEST运算,当且仅当四个byte都不为0的时候,ZR寄存器的值为0。
 
大家注意看,我上面的分析有一个错误!
 
1 XOR (!1) =0
 
错了,这里应该是1
 
换句话说,上面的代码无法区分最高一个byte最高bit为0,其他bit为1的情况。这是这种算法的一个死穴。当出现比如0x80112233这样的DWORD的时候,test    eax,81010100h 计算的结果跟0x00112233一样。当然最后的结果不会有问题,因为byte_3 -- byte_0里面会再次作判断。所以,如果用一连串的0x80112233作为字符串内容,strcpy的效率会大大下降
 
谢谢newer2k帮我找到我分析中的错误!
 
 
<think>嗯,用户遇到了“strcpy 找不到标识符”的问题。这个问题通常发生在C或C++编程中,当编译器无法识别strcpy函数的时候。我需要先理清可能的原因,然后逐步解释解决方法。 首先,strcpy是C标准库中的函数,位于string.h头文件里。用户可能忘记包含这个头文件,导致编译器找不到函数的声明。这时候,编译器会报错,提示未定义的标识符。所以第一个可能的解决办法就是检查是否包含了#include <string.h>。 其次,用户可能在使用C++的环境,但头文件的使用方式有问题。在C++中,通常建议使用#include <cstring>而不是C风格的string.h。不过,两种方式都可以,但需要确认是否正确包含,并且是否使用了正确的命名空间。比如,如果使用cstring,可能需要使用std命名空间,或者直接使用strcpy,但有时候编译器可能需要明确的命名空间限定,不过这种情况比较少见。 另外,用户可能拼写错误,比如将strcpy写成strpy或者strcopy,这种拼写错误也会导致找不到标识符。需要检查函数名是否正确。 还有一种情况是,用户可能在使用更安全的函数,比如strcpy_s,这是微软的CRT提供的函数,但如果在非Windows环境下或者没有定义相应的宏,可能会导致找不到标识符。这时候需要确认编译器是否支持该函数,或者是否包含正确的头文件。 还有可能是项目配置问题,比如编译器没有正确链接标准库,或者在某些嵌入式环境中,标准库被精简了,导致strcpy不可用。但这种情况相对少见,尤其是在普通的开发环境中。 接下来,我需要将这些可能性整理成步骤,帮助用户逐一排查。首先检查头文件,然后检查拼写,接着确认是否使用C++的正确头文件和命名空间,再考虑安全函数的情况,最后考虑项目配置的问题。同时,提供一个简单的示例代码,让用户参考正确的使用方法,这样他们可以对比自己的代码,找出问题所在。 最后,提醒用户如果问题依旧存在,可能需要检查编译器的设置或安装是否完整,确保标准库正确安装。这样用户就能系统地解决“strcpy 找不到标识符”的问题了。</think>$\texttt{strcpy}$ 是 C/C++ 标准库中的字符串拷贝函数。如果编译器提示“找不到标识符”,通常由以下原因导致: --- ### **1. 未包含头文件** $\texttt{strcpy}$ 定义在头文件 $\texttt{<string.h>}$ (C) 或 $\texttt{<cstring>}$ (C++) 中。 **解决方法**: ```c #include <string.h> // C 语言 // 或 #include <cstring> // C++ 语言(需配合命名空间 std::) ``` --- ### **2. 函数名拼写错误** 检查是否错误拼写为 $\texttt{strpy}$、$\texttt{strcopy}$ 等。 **正确形式**: ```c char* strcpy(char* dest, const char* src); ``` --- ### **3. C++ 命名空间问题(仅限 C++)** 在 C++ 中使用 $\texttt{<cstring>}$ 时,可能需要显式指定命名空间 $\texttt{std::}$: ```cpp std::strcpy(dest, src); ``` --- ### **4. 编译器安全设置** 某些编译器(如 MSVC)会禁用“不安全函数”如 $\texttt{strcpy}$,建议改用安全版本 $\texttt{strcpy\_s}$: ```c strcpy_s(dest, buffer_size, src); ``` --- ### **5. 代码示例验证** ```c #include <stdio.h> #include <string.h> // 必须包含头文件 int main() { char src[] = "Hello"; char dest[10]; strcpy(dest, src); // 正确使用 printf("%s", dest); return 0; } ``` --- ### **总结排查步骤** 1. 检查头文件包含 2. 核对函数名拼写 3. 确认编译器是否限制不安全函数 4. 尝试最小化代码复现问题 若问题仍存在,请检查编译环境配置(如标准库是否完整)。
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值