关于 John Winters 最近发布的多个静态返回缓冲区技术，brucemo@seanet.com 写道：
> 我认为这项技术很糟糕，因为它增加了不必要的“花哨”代码，
> 占用了 200 字节的静态数据，引入了需要
> 文档说明的内容（函数返回的缓冲区最终会被
> 覆盖），并引入了错误（由上述定时炸弹引起，
> 加上未能阅读或记住此文档），所有这些都是
> 为了省去用户在栈上分配缓冲区
> 并将该缓冲区指针传递给函数的麻烦。
>
> 对不起，但这个帖子让我感到不适。我无法忍受看到人们
> 将一个简单的函数无缘无故地变成一个复杂的“系统”。这种
> 编码方式会导致晦涩难懂的结构，让接手你代码的人
> 想要酗酒。
这取决于情况。在许多情况下，我完全同意你，认为不必要的复杂性或巧妙之处只会满足原始编码者的自尊心，并使其他人的生活变得痛苦。但并非总是如此。
软件工程就是管理复杂性。如果你到处都充满了复杂性，就像《戴帽子的猫回来了》中的粉红色粘液一样，你就会遇到问题。如果你或小猫 Z 能找到一种方法，至少将一部分复杂性扫到角落里，这样你就可以忽略它，除非你有机会进入那个角落，那么这样做就是好事。
我很懒惰。我喜欢简单、易于理解且能自我编写的代码。但我有时也会竭尽全力，花费一整天的时间编写一些极其复杂、过于通用的函数，如果这个函数能作为一个主力，让我在程序的其余部分可以推卸所有的繁重工作，从而使程序的其余部分变得愉快、轻而易举地编写。
至少在 C 语言中，从函数返回字符串可能有点困难，任何实现此目的的技术都比返回简单的非聚合值更复杂。当你指定任何函数接口时，函数应该做什么工作，调用者应该做什么工作，这通常是一个微妙的问题。规范正确且完整是不够的；如果它太麻烦，或者让调用者做太多的工作，那么潜在的调用者可能会感到气馁，并决定调用该函数太费事了，从而使拥有该函数的好处至少部分丧失。权衡可能是微妙的，并且可能取决于许多因素，但在这个案例中，不能单方面断定调用者总是应该为字符串结果分配空间，或者函数总是应该分配它。不同的情况可能需要不同的方法（至少为了达到最佳结果）。
多个静态返回缓冲区技术当然不是万能药。John 并没有提倡一直使用它，虽然我非常喜欢这项技术，但我几乎找不到实际使用它的机会。但偶尔，权衡下来，它会非常吸引人，并且（我相信）是合适的。
很久以前，我写了一篇长文，讨论了一些返回字符串和其他聚合体的选项及其各自的优点和适用性。我本来打算搜索一下，但昨晚，在一个我甚至不会去看的目录和机器上，我偶然发现了一个副本（碰巧是在查找要清理的目录以节省一些磁盘空间时）。就是它。
发件人：scs@eskimo.com (Steve Summit)
新闻组：comp.lang.c
主题：回复：返回字符串的函数 [重新发布]
日期：1997 年 6 月 23 日 22:15:07 GMT
Message-ID：<5omshb$4jg$1@eskinews.eskimo.com>
X-Original-Date：1997 年 6 月 18 日 18:53:06 GMT
X-Original-Message-ID：<5o9aqi$fcq$1@eskinews.eskimo.com>
另请参阅：<CrHu2G.D3B@eskimo.com>
在文章 <5o974l$df6$1@eskinews.eskimo.com> 中，我写道：
> 很久以前，我写了一篇长文，讨论了一些
> 返回字符串和其他聚合体的选项，以及它们的
> 相对优点和适用性。我本打算搜索一下
> 它，但昨晚，在一个目录和一台机器上
> 我甚至不会去看的，我偶然发现了一个副本（碰巧
> 是在查找要清理的目录以节省一些
> 磁盘空间时）。
我很高兴找到了它，以至于我忽略了脑海中一个挥之不去的感觉，即我刚找到的文章并没有像我记忆中的那样多地讨论权衡和相对优点。然后，当我把刚找到的那篇放到它所属的目录时，果然，那里还有一个文件（名称完全相同；确定性再次显灵），其中包含这篇文章（我已经为这次发布进行了少量编辑）。