《GLIBC strlen源代码分析》的评论 https://tonybai.com/2009/04/11/glibc-strlen-source-analysis/ 一个程序员的心路历程 Wed, 25 Mar 2026 09:21:20 +0000 hourly 1 http://wordpress.org/?v=3.2.1 作者：于小鱼 https://tonybai.com/2009/04/11/glibc-strlen-source-analysis/#comment-904 于小鱼 Sat, 16 Nov 2013 17:20:21 +0000 http://tonybai.com/2009/04/11/glibc-strlen%e6%ba%90%e4%bb%a3%e7%a0%81%e5%88%86%e6%9e%90/#comment-904 用ASCII 解释的部分是错的，你想复杂了。有一些值通过这个测试，但是没有全零字节是没问题的，因为它还会通过下面检查每个字节的测试， 显然不会通过，所以循环继续。 用ASCII 解释的部分是错的，你想复杂了。有一些值通过这个测试，但是没有全零字节是没问题的，因为它还会通过下面检查每个字节的测试， 显然不会通过，所以循环继续。

]]> 作者：gzm55 https://tonybai.com/2009/04/11/glibc-strlen-source-analysis/#comment-381 gzm55 Sun, 12 Apr 2009 15:17:02 +0000 http://tonybai.com/2009/04/11/glibc-strlen%e6%ba%90%e4%bb%a3%e7%a0%81%e5%88%86%e6%9e%90/#comment-381 HD的确是本百读不厌的书, 不过我也没看完, 今天中午特意看了下他对这部分的做法, 也相当精妙. 越界问题应该"几乎"不会出问题, 只是"标准"中说越界读取后果可能不可预知, 单对我们, 仅仅读取最多三个字节的垃圾数据, 我想最坏的后果是段错误, 读取非法内存. 但是段边界现在好像都需要4或8字节对齐了吧? HD的确是本百读不厌的书, 不过我也没看完, 今天中午特意看了下他对这部分的做法, 也相当精妙.

越界问题应该"几乎"不会出问题, 只是"标准"中说越界读取后果可能不可预知, 单对我们, 仅仅读取最多三个字节的垃圾数据, 我想最坏的后果是段错误, 读取非法内存. 但是段边界现在好像都需要4或8字节对齐了吧?

]]> 作者：gzm55 https://tonybai.com/2009/04/11/glibc-strlen-source-analysis/#comment-382 gzm55 Sun, 12 Apr 2009 14:15:21 +0000 http://tonybai.com/2009/04/11/glibc-strlen%e6%ba%90%e4%bb%a3%e7%a0%81%e5%88%86%e6%9e%90/#comment-382 仔细看了下代码, 对于扩展ascii字符和"\1\0"这种特殊情况, 虽然能通过那个条件, 但在37行开始的程序会将这些情况过滤掉. 看来代码的作者是假设char *里面的数据绝大部分是可读的标准ascii字符, 并对此做判断, 对于不满足假设的字符需要逐个检查. 这样的写法大部分情况下会比Hacker's Delight里面介绍的精确判定非零方法快. 仔细看了下代码, 对于扩展ascii字符和"\1\0"这种特殊情况, 虽然能通过那个条件, 但在37行开始的程序会将这些情况过滤掉.

看来代码的作者是假设char *里面的数据绝大部分是可读的标准ascii字符, 并对此做判断, 对于不满足假设的字符需要逐个检查. 这样的写法大部分情况下会比Hacker’s Delight里面介绍的精确判定非零方法快.

]]> 作者：gzm55 https://tonybai.com/2009/04/11/glibc-strlen-source-analysis/#comment-383 gzm55 Sun, 12 Apr 2009 11:14:05 +0000 http://tonybai.com/2009/04/11/glibc-strlen%e6%ba%90%e4%bb%a3%e7%a0%81%e5%88%86%e6%9e%90/#comment-383 在贴一个bstr lib给出的各个字符串库的比较 http://bstring.sourceforge.net/features.html 在贴一个bstr lib给出的各个字符串库的比较

http://bstring.sourceforge.net/features.html

]]> 作者：gzm55 https://tonybai.com/2009/04/11/glibc-strlen-source-analysis/#comment-384 gzm55 Sun, 12 Apr 2009 11:12:07 +0000 http://tonybai.com/2009/04/11/glibc-strlen%e6%ba%90%e4%bb%a3%e7%a0%81%e5%88%86%e6%9e%90/#comment-384 两个问题: 1. 这种方法要求最高位为零, 然后判断每个字节是否为正. 这种方法对于其他使用扩展ASCII编码的欧洲语系字符串怎么办呢? 字符串会以任何高位为1的字符结束(-128除外)~ 2. 移植性问题. 35行这句 longword = *longword_ptr++; 把字符串看成uint数组来读取, 当遇到字串结尾的时候, 有可能越界读取. 这显然不合标准, 在某些情况下会出错吧? 两个问题:
1. 这种方法要求最高位为零, 然后判断每个字节是否为正. 这种方法对于其他使用扩展ASCII编码的欧洲语系字符串怎么办呢? 字符串会以任何高位为1的字符结束(-128除外)~

2. 移植性问题. 35行这句 longword = *longword_ptr++; 把字符串看成uint数组来读取, 当遇到字串结尾的时候, 有可能越界读取. 这显然不合标准, 在某些情况下会出错吧?

]]>