x11 - Atom 为 64 位的系统上的 atom 属性的 XChangeProperty

Question

X11 协议(protocol)将 atom 定义为 32 位整数，但在我的系统上，Atom 类型 in 是 unsigned long 的 typedef，即 64 位整数。 Xlib 的手册说属性类型的最大大小为 32 位。这里似乎有一些冲突。我能想到三种可能的解决方案。

如果 Xlib 将 XA_ATOM 类型的属性视为特殊情况，那么您可以简单地为“格式”传递 32，为“数据”传递一个原子数组。这似乎是不干净和骇人听闻的，我高度怀疑这是正确的。

Xlib 的手册似乎很古老。由于 Atom 在我的系统上是 64 位长，即使 64 未列为允许值，我是否应该为“格式”参数传递 64？

我应该为“data”参数传递一个 uint32_t 值数组，而不是一个 Atom 数组？这似乎对我来说很可能是正确的解决方案，但这不是他们在我查找的使用 XChangeProperty 的某些资源中所做的，例如 SDL。

SDL 在设置 _NET_WM_WINDOW_TYPE 属性时似乎使用了解决方案 1，但我怀疑这可能是一个错误。在具有小端字节顺序(LSB 优先)的系统上，如果属性只有一个元素，这似乎可以工作。

有没有其他人遇到过这个问题？任何帮助表示赞赏。

Answer 1

对于属性例程，您总是希望传递一个“long”、“short”或“char”数组。这始终与实际位宽无关。因此，即使您的 long 或 atom 是 64 位，它也会在幕后转换为 32 位。

格式是使用的服务器端位数，而不是客户端。因此，对于格式 8，您必须传递一个 char 数组，对于格式 16，您始终使用短数组，对于格式 32，您始终使用长数组。这完全独立于给定机器上短或长的实际长度。诸如 Atom 或 Window 之类的 32 位值始终位于“long”中。

这可能看起来很奇怪，但这是有充分理由的，C 标准不保证存在与服务器上具有完全相同宽度的类型。例如，一台没有 native 16 位类型的机器。然而，'short' 保证至少有 16 位，而 long 保证至少有 32 位。因此，通过根据“短”和“长”来制作客户端 API，您既可以编写可移植代码，又可以始终为 C 类型中的完整 X id 留出空间。