Using jsn_totext() and xbuf_empty()



考虑以下简单的程序(在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。

我们没有这样做,因为我们显然不认为有人会重用相同的缓冲区。但是正如你的报告所显示的那样,这种情况可能会发生,所以我们将进行修改,以帮助其他用户避免同样的陷阱。

这是一种相关的反馈,随着时间的推移,产品会变得更好。

相关内容

  • 没有找到相关文章

最新更新