最有趣的Bug追踪 [英] Most Interesting Bug Track Down
问题描述
我认为分享追踪一个微妙或神秘的bug的经验可能会很有趣。我自己没有多少经验跟踪错误，但有一个特别想到的东西。
我写的可用处理字符串。按照我的代码的惯例，我将
变得极为有效。我做的一件事是更换，其中
可能是strlen的任何用法。类似于：
struct PtrAndLen {
char * p;
size_t len;
这可以用以下字符串初始化：
struct PtrAndLen const pal = {" Hello"，sizeof"你好"
从代码中的那一点开始，pal.len将用于代替
strlen。
代码增长了，在一个阶段我需要存储大约两个信息
$ b其中一个结构中的$ b字符串。为此，我使用了一个空分隔符，
例如：
PtrAndLen pal = {" Hello \0Bonjour"，sizeof" Hello \ 0Bonjour};
所有这一切都是由宏扩展的，所以我实际上有一些东西
就像：
MAKE_STR_INFO（Hello \0Bonjour）
然而，这个问题是strlen和pal.len有
不同的值，因为strlen只能读取第一个空的
终结符。无论如何，我必须在错误之前仔细阅读代码
跳出来。
我相信这里有几个常客更有意思故事...... :)
-
Frederick Gotham
I thought it might be interesting to share experiences of tracking down a
subtle or mysterious bug. I myself haven''t much experience with tracking
down bugs, but there''s one in particular which comes to mind.
I was writing usable which dealt with strings. As per usual with my code, I
made it efficient to the extreme. One thing I did was replace, where
possible, any usages of "strlen" with something like:
struct PtrAndLen {
char *p;
size_t len;
};
This could be initialised with a string as follows:
struct PtrAndLen const pal = { "Hello", sizeof "Hello" };
From that point forward in the code, "pal.len" would be used in place of
strlen.
The code grew though, and at one stage I needed to store info about two
strings in one of these structures. To do this, I used a null separator,
e.g.:
PtrAndLen pal = {"Hello\0Bonjour", sizeof "Hello\0Bonjour"};
All of this, however, was expanded by macros, so I actually had something
like:
MAKE_STR_INFO("Hello\0Bonjour")
The problem with this, however, was that "strlen" and "pal.len" had
different values, because strlen only read as far as the first null
terminator. Anyway, I had to read through the code in detail before the bug
jumped out at me.
I''m sure several regulars here have more interesting stories... :)
--
Frederick Gotham
推荐答案
Frederick Gotham写道：
Frederick Gotham wrote:
我认为分享追踪一个微妙或神秘的bug的经验可能会很有趣。我自己没有多少经验跟踪错误，但有一个特别想到的东西。
我写的可用处理字符串。按照我的代码的惯例，我将
变得极为有效。我做的一件事是更换，其中
可能是strlen的任何用法。类似于：
struct PtrAndLen {
char * p;
size_t len;
这可以用以下字符串初始化：
struct PtrAndLen const pal = {" Hello"，sizeof"你好"
从代码中的那一点开始，pal.len将用于代替
strlen。
代码增长了，在一个阶段我需要存储大约两个信息
$ b其中一个结构中的$ b字符串。为此，我使用了一个空分隔符，
例如：
PtrAndLen pal = {" Hello \0Bonjour"，sizeof" Hello \ 0Bonjour};
所有这一切都是由宏扩展的，所以我实际上有一些东西
就像：
MAKE_STR_INFO（Hello \0Bonjour）
然而，这个问题是strlen和pal.len有
不同的值，因为strlen只能读取第一个空的
终结符。无论如何，我必须在错误之前详细阅读代码
跳出来。
I thought it might be interesting to share experiences of tracking down a
subtle or mysterious bug. I myself haven''t much experience with tracking
down bugs, but there''s one in particular which comes to mind.
I was writing usable which dealt with strings. As per usual with my code, I
made it efficient to the extreme. One thing I did was replace, where
possible, any usages of "strlen" with something like:
struct PtrAndLen {
char *p;
size_t len;
};
This could be initialised with a string as follows:
struct PtrAndLen const pal = { "Hello", sizeof "Hello" };
From that point forward in the code, "pal.len" would be used in place of
strlen.
The code grew though, and at one stage I needed to store info about two
strings in one of these structures. To do this, I used a null separator,
e.g.:
PtrAndLen pal = {"Hello\0Bonjour", sizeof "Hello\0Bonjour"};
All of this, however, was expanded by macros, so I actually had something
like:
MAKE_STR_INFO("Hello\0Bonjour")
The problem with this, however, was that "strlen" and "pal.len" had
different values, because strlen only read as far as the first null
terminator. Anyway, I had to read through the code in detail before the bug
jumped out at me.
看起来它可能没有足够高的跳跃：即使没有嵌入的''\ 0''字符，也会出现错误
。
-
Eric Sosman
es ***** @ acm-dot-org.inva lid
Looks like it may not have jumped high enough: The bug is there
even without embedded ''\0'' characters.
--
Eric Sosman
es*****@acm-dot-org.invalid
2006年11月24日星期五22:12:15 GMT，Frederick Gotham
< fg ******* @ SPAM.com在comp.lang.c中写道：
On Fri, 24 Nov 2006 22:12:15 GMT, Frederick Gotham
<fg*******@SPAM.comwrote in comp.lang.c:
>
我认为分享追踪一个微妙或神秘的bug的经验可能会很有趣。我自己没有多少经验跟踪错误，但有一个特别想到的东西。
我写的可用处理字符串。按照我的代码的惯例，我将
变得极为有效。我做的一件事是更换，其中
可能是strlen的任何用法。类似于：
>
I thought it might be interesting to share experiences of tracking down a
subtle or mysterious bug. I myself haven''t much experience with tracking
down bugs, but there''s one in particular which comes to mind.
I was writing usable which dealt with strings. As per usual with my code, I
made it efficient to the extreme. One thing I did was replace, where
possible, any usages of "strlen" with something like:
为什么像往常一样？一旦你的应用程序正常工作，它就太慢了吗？你有资料或测试并证明这个
是瓶颈吗？
Why "as usual"? Once you had the application working correctly, was
it too slow? Did you profile or otherwise test and to prove that this
was a bottleneck?
struct PtrAndLen {
char * p;
size_t len;
};
这可以用字符串初始化，如下所示：
struct PtrAndLen const pal = {" Hello"，sizeof" Hello"
从代码中的那一点开始，pal.len将用于代替
strlen。
代码增长了，在一个阶段我需要存储大约两个信息
$ b其中一个结构中的$ b字符串。为此，我使用了一个空分隔符，
例如：
PtrAndLen pal = {" Hello \0Bonjour"，sizeof" Hello \ 0Bonjour"};
struct PtrAndLen {
char *p;
size_t len;
};
This could be initialised with a string as follows:
struct PtrAndLen const pal = { "Hello", sizeof "Hello" };
From that point forward in the code, "pal.len" would be used in place of
strlen.
The code grew though, and at one stage I needed to store info about two
strings in one of these structures. To do this, I used a null separator,
e.g.:
PtrAndLen pal = {"Hello\0Bonjour", sizeof "Hello\0Bonjour"};
现在，由于过早优化，您违反了
设计。你正在用不是字符串的东西初始化，或者更确切地说是字符串加上其他东西。
So now, thanks to premature optimization, you have violated your
design. You are initializing with something that is not a string, or
more precisely a string plus something else.
然而，所有这一切，由宏扩展，所以我实际上有一些东西
喜欢：
MAKE_STR_INFO（" Hello \0Bonjour"）
然而，这个问题是strlen和strlen。和pal.len有
不同的值，因为strlen只能读取第一个空的
终结符。无论如何，我必须在错误之前详细阅读代码
跳出来。
All of this, however, was expanded by macros, so I actually had something
like:
MAKE_STR_INFO("Hello\0Bonjour")
The problem with this, however, was that "strlen" and "pal.len" had
different values, because strlen only read as far as the first null
terminator. Anyway, I had to read through the code in detail before the bug
jumped out at me.
这怎么可能有问题？你刚才说你已经取消了所有使用
strlen（）。
How could that be a problem? You just said you eliminated all use of
strlen().
我相信这里的几位常客会有更多有趣的故事。 。:)
I''m sure several regulars here have more interesting stories... :)
听起来像是一个糟糕的设计，因为违反了
使用中的限制而更加恶化。
-
Jack Klein
主页： http://JK-Technology.Com
常见问题解答
comp.lang.c http://c-faq.com/
comp.lang.c ++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c ++
http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html
Sounds like a poor design, aggravated by violating its constraints in
use.
--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html
Eric Sosman：
Eric Sosman:
看起来它可能没有跳得足够高：即使没有嵌入的''\0''字符，也会出现错误
。
Looks like it may not have jumped high enough: The bug is there
even without embedded ''\0'' characters.
是的，我应该提到我采用了sizeofHello" - 1进入
账户。
-
Frederick Gotham
Ah yes, I should have mentioned that I took the "sizeof "Hello" - 1" into
account.
--
Frederick Gotham
这篇关于最有趣的Bug追踪的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
