x64平台自定义public strlen函数是否需检查NULL地址？

这是个特别务实的问题——毕竟写公共接口的时候，性能和健壮性的平衡永远是绕不开的点。咱们结合场景和规范来拆解：

先看标准库的规矩 #

C标准里明确规定，给strlen传入NULL属于未定义行为——意思是标准库根本不保证处理这种情况，程序崩溃是完全符合预期的结果。如果你的自定义strlen是要对标标准库的行为，那完全可以跳过NULL检查，因为调用者本来就有义务保证传入有效的字符串地址。

分场景看必要性 #

内部使用的公共函数 #

如果这个函数是给团队内部同事用的，大家都清楚调用规范，那加NULL检查反而有点多余：

• 从性能上说，test rax, rax; jz .ret0这两条指令虽然短，但如果是高频调用的场景，积少成多也会有性能损耗；
• 从调试角度说，直接崩溃反而能快速定位问题——总比悄悄返回0，让后续代码拿着错误的长度继续执行，最后出现更难排查的逻辑bug要强。

对外公开的库API #

如果这个函数是作为对外发布的库的公开接口，那情况就不一样了：外部用户可能不熟悉你的调用规则，不小心传了NULL进来。这时候你有两个选项：

1. 依然不检查：好处是性能没损失，但用户体验差，可能会抱怨你的库“莫名其妙崩溃”；
2. 加上检查：但不建议直接返回0（这会偏离标准库的未定义行为，调用者如果依赖这个逻辑，换成标准库strlen就会出问题），更合理的做法是触发一个明确的错误信号——比如调用int3触发断点，或者返回一个特殊的错误标识（如果你的函数设计支持的话），至少让用户清楚问题出在传入了NULL，而不是摸不着头脑。

性能的权衡 #

strlen属于可能被高频调用的基础函数，每一条额外的指令都值得掂量。x64上的test+jz是两条短指令，单次调用开销很小，但如果是在循环里或者百万级别的调用场景，还是会有可感知的性能影响。如果你的核心目标是极致性能，那完全可以把检查的责任交给调用者。

总结 #

没有绝对的“必须加”或“必须不加”，核心看你的函数定位：

• 若对标标准库、追求极致性能、面向内部使用者：不需要加NULL检查；
• 若作为对外公开API、希望提升健壮性：可以加检查，但要明确错误行为，别悄悄返回0。

内容的提问来源于stack exchange，提问作者ELHASKSERVERS