谁能指出我strlen()在 GCC 中的定义？我已经发布 4.4.2 版大约半小时了（同时谷歌搜索疯狂），我似乎无法找到strlen()实际实施的位置。
问问题
60558 次
10 回答
33
您应该查看 glibc，而不是 GCC——它似乎是在中定义的strlen.c——这里是glibc 2.7 版的 strlen.c的链接……这里是strlen.c 的在线 glibc SVN 存储库的链接。
您应该查看glibc而不是 gcc 的原因是：
GNU C 库用作GNU 系统和大多数带有 Linux 内核的系统中的C 库。
于 2009-11-14T04:36:26.540 回答
13
这是bsd的实现
size_t
strlen(const char *str)
{
const char *s;
for (s = str; *s; ++s)
;
return (s - str);
}
于 2009-11-14T04:40:10.357 回答
13
我意识到这个问题已经有 4 年的历史了，但是如果你不这样做，gcc 通常会包含它自己#include <string.h>的 strlen 副本，并且没有任何答案（包括接受的答案）可以解释这一点。如果你忘记了，你会得到一个警告：
file_name:line_number: warning: incompatible implicit declaration of built-in function 'strlen'
并且 gcc 将内联它的副本，它在 x86 上是 repnz scasb asm 变体，除非您通过 -Werror 或 -fno-builtin。与此相关的文件在gcc/config/<platform>/<platform>.{c,md}
它也由 gcc/builtins.c 控制。如果您想知道 strlen() 是否以及如何优化为常量，请参阅tree c_strlen(tree src, int only_value)此文件中定义的函数。它还控制 strlen（以及其他）如何展开和折叠（基于前面提到的配置/平台）
于 2013-11-10T03:18:32.243 回答
5
在glibc/string/strlen.c中定义
#include <string.h>
#include <stdlib.h>
#undef strlen
#ifndef STRLEN
# define STRLEN strlen
#endif
/* Return the length of the null-terminated string STR. Scan for
the null terminator quickly by testing four bytes at a time. */
size_t
STRLEN (const char *str)
{
const char *char_ptr;
const unsigned long int *longword_ptr;
unsigned long int longword, himagic, lomagic;
/* Handle the first few characters by reading one character at a time.
Do this until CHAR_PTR is aligned on a longword boundary. */
for (char_ptr = str; ((unsigned long int) char_ptr
& (sizeof (longword) - 1)) != 0;
++char_ptr)
if (*char_ptr == '\0')
return char_ptr - str;
/* All these elucidatory comments refer to 4-byte longwords,
but the theory applies equally well to 8-byte longwords. */
longword_ptr = (unsigned long int *) char_ptr;
/* Bits 31, 24, 16, and 8 of this number are zero. Call these bits
the "holes." Note that there is a hole just to the left of
each byte, with an extra at the end:
bits: 01111110 11111110 11111110 11111111
bytes: AAAAAAAA BBBBBBBB CCCCCCCC DDDDDDDD
The 1-bits make sure that carries propagate to the next 0-bit.
The 0-bits provide holes for carries to fall into. */
himagic = 0x80808080L;
lomagic = 0x01010101L;
if (sizeof (longword) > 4)
{
/* 64-bit version of the magic. */
/* Do the shift in two steps to avoid a warning if long has 32 bits. */
himagic = ((himagic << 16) << 16) | himagic;
lomagic = ((lomagic << 16) << 16) | lomagic;
}
if (sizeof (longword) > 8)
abort ();
/* Instead of the traditional loop which tests each character,
we will test a longword at a time. The tricky part is testing
if *any of the four* bytes in the longword in question are zero. */
for (;;)
{
longword = *longword_ptr++;
if (((longword - lomagic) & ~longword & himagic) != 0)
{
/* Which of the bytes was the zero? If none of them were, it was
a misfire; continue the search. */
const char *cp = (const char *) (longword_ptr - 1);
if (cp[0] == 0)
return cp - str;
if (cp[1] == 0)
return cp - str + 1;
if (cp[2] == 0)
return cp - str + 2;
if (cp[3] == 0)
return cp - str + 3;
if (sizeof (longword) > 4)
{
if (cp[4] == 0)
return cp - str + 4;
if (cp[5] == 0)
return cp - str + 5;
if (cp[6] == 0)
return cp - str + 6;
if (cp[7] == 0)
return cp - str + 7;
}
}
}
}
libc_hidden_builtin_def (strlen)
于 2018-04-25T12:38:42.220 回答
5
glibc 2.26 有几个手工优化的汇编实现strlen
从 开始glibc-2.26，快速：
git ls-files | grep strlen.S
在 glibc 树中显示了针对所有主要拱门和变体的十几个汇编手工优化实现。
特别是，仅 x86_64 就有 3 个变体：
sysdeps/x86_64/multiarch/strlen-avx2.S
sysdeps/x86_64/multiarch/strlen-sse2.S
sysdeps/x86_64/strlen.S
确定使用哪一个的一种快速而肮脏的方法是逐步调试测试程序：
#include <assert.h>
#include <stdlib.h>
#include <string.h>
#include <stdio.h>
int main(void) {
size_t size = 0x80000000, i, result;
char *s = malloc(size);
for (i = 0; i < size; ++i)
s[i] = 'a';
s[size - 1] = '\0';
result = strlen(s);
assert(result == size - 1);
return EXIT_SUCCESS;
}
编译：
gcc -ggdb3 -std=c99 -O0 a.c
开场白：
disass main
包含：
callq 0x555555554590 <strlen@plt>
因此正在调用 libc 版本。
经过几个si指令级步骤，GDB 达到：
__strlen_avx2 () at ../sysdeps/x86_64/multiarch/strlen-avx2.S:52
52 ../sysdeps/x86_64/multiarch/strlen-avx2.S: No such file or directory.
这告诉我strlen-avx2.S使用过。
然后，我进一步确认：
disass __strlen_avx2
并将反汇编与 glibc 源进行比较。
使用 AVX2 版本并不奇怪，因为我有一个i7-7820HQ CPU，发布日期为 2017 年第一季度并支持 AVX2，而AVX2是最先进的组装实现，发布日期为 2013 年第二季度，而SSE2更多从 2004 年开始。
这就是 glibc 的大部分硬核来自的地方：它有很多经过拱优化的手写汇编代码。
在 Ubuntu 17.10、gcc 7.2.0、glibc 2.26 中测试。
-O3
TODO: with -O3, gcc 不使用 glibc 的strlen，它只是生成内联汇编，在：https ://stackoverflow.com/a/19885891/895245
是因为它可以优化得更好吗？但是它的输出不包含AVX2指令，所以我觉得不是这样的。
https://www.gnu.org/software/gcc/projects/optimize.html提到：
GCC优化器的不足
glibc 有各种字符串函数的内联汇编版本；GCC 在相同的架构上有一些，但不一定是相同的。可以为更多功能提供额外的 optab 条目，如 ffs 和 strlen 条目，包括 memset、strchr、strcpy 和 strrchr。
我的简单测试表明该-O3版本实际上更快，因此 GCC 做出了正确的选择。
于 2018-05-06T11:35:30.947 回答
4
虽然最初的发布者可能不知道这个或一直在寻找这个，但 gcc 在内部内联了许多它自己定义的所谓“内置”c 函数，包括一些 mem*() 函数和（取决于gcc 版本）strlen。在这种情况下，库版本基本上从未使用过，并且将人员指向 glibc 中的版本严格来说并不正确。（它这样做是出于性能原因——除了内联本身产生的改进之外，gcc 在提供函数时“知道”函数的某些事情，例如，strlen 是一个纯函数，因此它可以优化多个调用，或者在没有发生别名的 mem*() 函数的情况下。）
有关这方面的更多信息，请参阅http://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html
于 2012-02-18T03:05:11.737 回答
3
这是你想要的？strlen() 源。有关更多信息，请参阅git 存储库。如果您想获取它们而不是查看 Web 视图，glibc 资源页面有指向 git 存储库的链接。
于 2009-11-14T04:39:55.563 回答
3
对于此类问题， Google 代码搜索是一个很好的起点。它们通常指向功能的各种不同来源和实现。
在您的特定情况下：GoogleCodeSearch(strlen)
谷歌代码搜索于 2013 年 3 月完全关闭
于 2009-11-14T04:50:13.533 回答
-1
我意识到这是个老问题，你可以在这里找到 github 上的 linux 内核源代码，strlen() 的 32 位实现可以在 github 上的strlen_32.c中找到。提到的文件有这个实现。
#include <linux/types.h>
#include <linux/string.h>
#include <linux/module.h>
size_t strlen(const char *s)
{
/* Get an aligned pointer. */
const uintptr_t s_int = (uintptr_t) s;
const uint32_t *p = (const uint32_t *)(s_int & -4);
/* Read the first word, but force bytes before the string to be nonzero.
* This expression works because we know shift counts are taken mod 32.
*/
uint32_t v = *p | ((1 << (s_int << 3)) - 1);
uint32_t bits;
while ((bits = __insn_seqb(v, 0)) == 0)
v = *++p;
return ((const char *)p) + (__insn_ctz(bits) >> 3) - s;
}
EXPORT_SYMBOL(strlen);
于 2016-09-28T08:05:11.620 回答
-2
您可以使用此代码，越简单越好！
size_t Strlen ( const char * _str )
{
size_t i = 0;
while(_str[i++]);
return i;
}
于 2018-02-24T20:38:21.583 回答