☰

X11 仍然对应用程序资源字符串有硬编码限制吗？

tag-icon • tag-icon x11 xorg xterm x-resources
X11 仍然对应用程序资源字符串有硬编码限制吗？

xterm(1) 手册页指出：

由于X 库中对资源总数的硬编码限制（最多 400 个），当启用宽字符支持和 luit 时，将省略 256 色的资源。如果仅允许部分资源，除了行为不一致之外，确定准确的截止也很困难，并且如果资源数量超过限制，X 库往往会崩溃。调色板仍然初始化为相同的默认值，并且可以通过控制序列进行修改。

我怀疑此信息已过时。任何人都可以确认这对于像 X.Org 1.12 (X11R7) 这样的当代 X 实现来说是（或不再是）问题吗？如果这个限制仍然存在，那么有人需要在 X11 源代码中的哪里寻找它？

答案1

你指的是xorg/lib/libXt/Resource.c

#define MAXRESOURCES  400

稍后在相同的文件:

} else if (num_resources >= MAXRESOURCES) {
    XtAppWarningMsg(XtWidgetToApplicationContext(widget),
    "invalidResourceCount","getResources",XtCXtToolkitError,
          "too many resources",
      (String *)NULL, (Cardinal *)NULL);
return NULL;

Xorg 开发人员不太可能改变这一点，因为应用程序很少可以使用那么多资源。

xterm 中 256 色的原始方案（在1999年）为每种颜色分配单独的资源。

的变更日志补丁 #188 - 2004/5/12 - XFree86 4.4.99.6说：

  • 修改 256 色和 88 色的初始化，以便超过 16 色的颜色通常不是 X 资源。这可以解决 Xt 中的硬编码限制，当同时配置 256 色和 luit 时，该限制会破坏 xterm（Noah Friedman 的报告）。

报告提到了luit，但除此之外，还有其他资源用于 UTF-8、语言环境等。有时需要进行一些调整，例如，补丁 #191 - 2004/6/6 - XFree86 4.4.99.7

  • 修复 ifdef 的 for OPT_COLOR_RES2，以便补丁 #188 中引入的假资源表在为空时不会被编译。这恰好适用于 gcc（Joel Konkle-Parker 的报告）。

和补丁 #250 - 2009/10/13:

  • 通过为 88 色模型启用资源来改进补丁 #188 的解决方法。
  • xterm 联机帮助页中记录了资源 color16 到 color255 的有限可用性，如补丁 #188 (Ubuntu #438850) 中所述。

该程序仍然可以使用 256 种颜色资源（无 UTF-8）构建，但现在这样做的次数较少。

就像健全性检查一样，xterm 有这个块（调试时打开）：

TRACE(("VTInitialize wnew %p, %d / %d resources\n",
       (void *) wnew, XtNumber(xterm_resources), MAXRESOURCES));
assert(XtNumber(xterm_resources) < MAXRESOURCES);

跟踪日志显示

VTInitialize wnew 0xb98a90, 232 / 400 resource

因此，由于不使用额外的 240 (256-16) 颜色资源，因此不会立即出现资源耗尽的风险。

相关内容