考虑以下简单的程序(在gwan v4.3.14上运行):
xbuf_t buf;
xbuf_init(&buf);
xbuf_cat(&buf, "{"num":-1}"); // simple json string
jsn_t *jrec = jsn_frtext(buf.ptr, "rec"); // parse it
jsn_t *jnum = jsn_byname(jrec, "num",1); // look for the element
jsn_updt(jnum, 2); // change the value to positive 2
xbuf_empty(&buf); // reuse the buffer
puts(jsn_totext(&buf, jrec, 0)); // lets take a look
预期输出是{"num":2}
,结果是{"num":-2}
。
不知何故,jsn_totext()
重用了空的xbuffer,并用'2'覆盖了'1'的位置。但是如果我要做jsn_update(jnum, 100)
,输出将是正确的。
这是一个bug还是我误解了xbuf_empty()
的功能?
我问这个问题是因为使用xbuf_reset()
而不是xbuf_empty()
使此代码按预期工作。
您几乎已经回答了这个问题:代码中的问题来自(错误地)使用xbuf_empty()
函数。
让我们解释一下原因:
手册解释说jsn_totext()
将输出存储在一个xbuffer中,然后您必须"在处理完文本后调用xbuf_free(text)"。
这意味着目标xbuffer应该是未分配的,因为jsn_totext()
将分配它。
你说使用xbuf_reset()
工作。这是因为该调用是xbuf_init()
函数的已弃用别名。
你的困惑来自xbuf_reset()
太接近xbuf_empty()
的事实…这就是为什么我们改名为xbuf_init()
(几年前)。
现在,你的问题提出了一个有趣的问题,这就是为什么我们不认为重用或重新初始化已经分配给jsn_totext()
的xbuffers。
我们没有这样做,因为我们显然不认为有人会重用相同的缓冲区。但是正如你的报告所显示的那样,这种情况可能会发生,所以我们将进行修改,以帮助其他用户避免同样的陷阱。
这是一种相关的反馈,随着时间的推移,产品会变得更好。