在C中,该memmem函数用于定位存储区中的特定字节序列.它可以被同化strstr,专用于以null结尾的字符串.
是否有任何特殊原因使此函数可用作GNU扩展,而不是直接在标准库中？手册说明:
这个功能在Linux库中被破坏,包括libc 5.0.9; 在那里,针和干草堆参数被互换,并且返回了第一次出现针的末尾的指针.
旧的和新的libc都有错误,如果针是空的,则返回haystack-1(而不是haystack).并且glibc 2.0使情况变得更糟,返回指向haystack的最后一个字节的指针.这在glibc 2.1中得到修复.
我可以看到它经历了几次修复,但我想知道为什么它不像strstr某些发行版那样直接可用(如果不是更多).它是否仍然会带来实施问题？
编辑:动机.如果标准反过来决定它,我不会问这个问题:包括memmem但不是strstr.确实,strstr可能是这样的:
memmem(str, strlen(str), "search", 6);
考虑到在C函数中通常需要数据块和它的长度,但是稍微复杂但仍然是一个非常合乎逻辑的单行.
编辑(2):评论和答案的另一个动机.引用Theolodis:
并非每个函数都是必需的,或者至少是大多数C开发人员,因此它实际上会使标准库变得不必要的巨大.
嗯,我完全同意,在使图书馆更轻,更快的时候,我总是在这里.但那么......为什么两者strncpy和memcpy(来自凯尔塔尔的评论)......？我几乎可以问:为什么穷人memmem被"黑色"？
从历史上看，在标准第一次修订之前，C 语言是由编译器作者编写的。
在 的情况下strstr，它有点不同，因为它是由 C 委员会引入的，C89 Rationale 文件告诉我们：
“该
strstr函数是委员会的一项发明。它被包含作为高效算法或内置子串指令的挂钩。”
C 委员会没有解释为什么它没有制定一个不限于字符串的更通用的函数，因此任何推理都可能只是猜测。我唯一的猜测是，用例被认为不够重要，不足以用通用的memmem代替strstr。请记住，C 的目标中有这样的要求（在 C99 基本原理中）“保持语言小而简单”。甚至 POSIX 也没有考虑将其包含在内。
无论如何，据我所知，没有人提出任何缺陷报告或建议memmem。