GCC中strlen（）的实现在哪里？

有人能指出我在GCC中对strlen()的定义吗？ 我现在大约半小时一直在试用版本4.4.2（当谷歌疯狂时），我似乎无法找到strlen()实际实现的位置。

Answer 1

您应该查看glibc，而不是GCC – 它似乎是在strlen.c定义的 – 这里是strlen.c for glibc 2.7的链接…这里是strlen的glibc SVN存储库的链接。 c 。

你应该看glibc而不是gcc的原因是：

GNU C库用作GNU系统中的 C库，大多数系统使用Linux内核。

Answer 2

我意识到这个问题已经过了4年了，但是如果你没有#include ，那么gcc通常会包含它自己的strlen副本，并且没有任何答案（包括接受的答案）。 如果您忘了，您会收到警告：

file_name:line_number: warning: incompatible implicit declaration of built-in function 'strlen'

并且gcc将内联其副本，在x86上是repnz scasb asm变体，除非你传递-Werror或-fno-builtin。 与此相关的文件位于gcc/config//.{c,md}

它也由gcc / builtins.c控制。 如果您想知道strlen（）是否以及如何针对常量进行优化，请参阅此文件中定义为tree c_strlen(tree src, int only_value)的函数。 它还控制strlen（以及其他）如何扩展和折叠（基于前面提到的配置/平台）

Answer 3

这是bsd实现

 size_t strlen(const char *str) { const char *s; for (s = str; *s; ++s) ; return (s - str); } 

Answer 4

这是你想要的？ strlen（）来源 。 有关更多信息，请参阅git存储库 。 如果你想抓住它们而不是查看网页视图，那么glibc资源页面会链接到git存储库。

Answer 5

虽然原始海报可能不知道这个或者一直在寻找这个，但是gcc内部内联了一些所谓的“内置”c函数，它自己定义，包括一些mem *（）函数和（取决于gcc版）strlen。 在这种情况下，库版本基本上从未使用过，并且将该人指向glibc中的版本并不严格地说是正确的。 （它出于性能原因这样做 – 除了内联本身产生的改进之外，gcc在提供函数时“知道”关于函数的某些事情，例如，strlen是纯函数，因此它可以因此优化多个调用，或者在mem *（）函数中没有发生混叠。）

有关这方面的更多信息，请参阅http://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html

Answer 6

谷歌代码搜索是这类问题的一个很好的起点。 它们通常指向函数的各种不同来源和实现。

在您的特定情况下： GoogleCodeSearch（strlen）

Google Code Search于2013年3月完全关闭

Answer 7

在glibc / string / strlen.c中定义

 #include  #include  #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) 

Answer 8

我意识到这是一个老问题，你可以在这里找到github上的linux内核源码，strlen（）的32位实现可以在github上的strlen_32.c中找到。 提到的文件有这个实现。

 #include  #include  #include  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); 

Answer 9

你可以使用这个代码，越简单就越好！

 size_t Strlen ( const char * _str ) { size_t i = 0; while(_str[i++]); return i; } 

Answer 10

glibc 2.26有几个手动优化的strlen组件实现

截至glibc-2.26 ，快速：

 git ls-files | grep strlen.S 

在glibc树中显示了针对所有主要拱门和变体的十几个assembly手动优化实施。

特别是，仅x86_64有3种变体：

 sysdeps/x86_64/multiarch/strlen-avx2.S sysdeps/x86_64/multiarch/strlen-sse2.S sysdeps/x86_64/strlen.S 

确定使用哪一个的快速而肮脏的方法是逐步调试测试程序：

 #include  #include  #include  #include  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 ac 

蝙蝠：

 disass main 

包含：

 callq 0x555555554590  

所以正在调用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是最先进的assembly实施，发布日期为2013年第二季度，而SSE2则更多从2004年开始。

这是glibc硬性的很大一部分来自：它有很多arch优化的手写汇编代码。

测试在Ubuntu 17.10，gcc 7.2.0，glibc 2.26。

-O3

TODO：使用-O3 ，gcc不使用glibc的strlen ，它只生成内联汇编，如下所述： https ： //stackoverflow.com/a/19885891/895245

是因为它可以更好地优化吗？ 但它的输出不包含AVX2指令，所以我觉得情况并非如此。

https://www.gnu.org/software/gcc/projects/optimize.html提及：

GCC优化器的缺陷

glibc具有各种字符串函数的内联汇编程序版本; GCC在同一架构上有一些但不一定相同。 可以为包括memset，strchr，strcpy和strrchr在内的多个函数提供其他optab条目，例如ffs和strlen的条目。

我的简单测试表明-O3版本实际上更快，因此GCC做出了正确的选择。

提问者： https ： //www.quora.com/unanswered/How-does-GCC-know-that-its-builtin-implementation-of-strlen-is-faster-than-glibcs​​-when-using-optimization-level -O3