共计 1003 个字符，预计需要花费 3 分钟才能阅读完成。
Visual Studio Code 又呈现新 Bug 了！
近日，一位名为 na-an 的用户在应用 Microsoft 的 Visual Studio Code 编辑器（以下简称 VS Code）关上文件夹时，发现其目录中会主动创立许多带有有效代码的空文件。随后，该用户便将一个相干问题公布到 VS Code GitHub 存储库上，一时间引发了热烈的探讨，不少用户都示意他们同样受到了该“破绽”的困扰。
据显示，这些主动创立的来及文件有些文件名长，有些短，且这些文件名并不是无效的 unicode（如图中的 \312\316\361 是八进制）。
通过剖析之后，发现这些随机创立的文件，仿佛来自正在运行的过程内存转储，其中就蕴含了通常呈现在可执行文件中的字符串，以及看起来像是带有堆栈损坏或越界的指针问题（pointer issue）。
除了疯狂地创立空文件外，这次发现的 VS Code“破绽”还会随机批改用户文件。比方以用户名 daantimmer 打头的文件里所有内容都被革除了，都变成了 0 KB，这个状况是最蹩脚的，因为你无奈保障是否提前给文件备份。
当然，该破绽不仅限于以后的工作区文件夹，它甚至能够清空一些系统文件 / 文件夹。
目前，这个破绽已呈现在 Windows 和 Linux 等不同的零碎上。据理解，该破绽的“受害者”都有个共同点：他们都写 C++ 代码，应用 VS CODE 的 C++ 扩大。因为有用户发现，当他试图禁用所有扩大后，该问题就隐没了；如果将 C++ 扩大转换为稳固版本（1.8.4），问题也会隐没。
所以，以上事实均证实了该破绽的根本原因就在于 VS CODE + C++ 扩大 1.9.4 的预公布版本，因为它临时不稳固，且具备以上文件系统缺点（然而，如果查看 VS CODE 自动更新性能，它将自动更新到 C++ 扩大 1.9.4 的预公布版本）。
当然，C++ 扩大的开发人员并不知道 1.9.4 版本到底哪里有问题。而内存损坏问题仿佛又与 C++ 扩大中的几个长期存在但未解决的文件损坏谬误无关：α4573 和 5061。
因而，目前的猜想就是：1.9.4 版本意外地应用未初始化的内存，且指针问题（pointer issue）引起了一些文件系统谬误，因对不遵循古代 C++ 编码准则的内部第三方子系统进行批改，就会阻止或检测未初始化指针的应用。
想要解决这个问题的办法很简略，那就是 —— 别装置 1.9.4 版本的 C++ 扩大。当然，在 1.9.5、1.9.3、1.8.4 以及新公布的 1.9.6 版本里不存在这个问题。
