Json 使用jsn_totext（）和xbuf_empty（）函数

考虑以下简单程序（在gwan v4.3.14上运行）：

预期的输出是

{“num”：2}

，但结果却是

{“num”：-2}

不知何故，

jsn_totext（）

重用了清空的xbuffer，并用“2”重写了“1”的位置。但是如果我要做

jsn\u更新（jnum，100）

，输出将是正确的

这是一个bug还是我误解了

xbuf\u empty（）

的功能

---

我之所以问这个问题，是因为使用

xbuf\u reset（）

而不是

xbuf\u empty（）

使此代码按预期工作。

您几乎已经回答了这个问题：代码中的问题来自

xbuf\u empty（）

函数的（错误）使用

让我们解释一下原因：

本手册解释说，

jsn_totext（）

将输出存储在xbuffer中，然后必须使用“”

这意味着目标xbuffer应该是未分配的，而

jsn_totext（）

将分配它

您说过使用

xbuf\u reset（）

有效。这是si，因为此呼叫是一个

您的困惑是因为

xbuf\u reset（）

太接近

xbuf\u empty（）

。。。这就是为什么我们将其重命名为

xbuf_init（）

（几年前）

现在，您的问题提出了一个有趣的问题，这就是为什么我们不考虑重用或重新初始化传递给

jsn_totext（）

的已分配的xbuffers

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

---

这是一种相关的反馈，随着时间的推移，它使产品变得更好。感谢您的投入。

顺便说一句，我对gwan的性能印象深刻。如果不是在守护进程模式下频繁地重启应用程序，我可能会考虑将其用于严肃的生产部署。这些系统的兼容性在V4.5+中被固定，而今天的版本是V5.5（一年后：第一个版本号是一年，第二个版本是月份）。我们将在今年晚些时候公开发布一个重大更新，但为了防止其他免费的系统修改破坏游戏，在我们发布基于G-WAN的云服务之前，我们不会发布。非常感谢您的回答。我认为重新使用xbuf会有更好的性能，因为它不需要再次释放内存和分配内存。仅使用xbuf_empty（）似乎对所有其他函数都有效——当然，jsn_totext（）除外。顺便说一句，我可以让jsn_totext（）在不取消xbuf分配的情况下输出正确的字符串。简单地说：xbuf_clear（&buf）；xbuf_为空（&buf）；当然，如果缓冲区很大，xbuf_clear（）将占用相当多的CPU周期。对。如果我的回答对你有意义，请“接受”。这将帮助其他人找到这个问题的解决办法。

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