我想知道是否有人可以对 pset4 中位图示例中使用的打包属性的含义提供更完整的解释。
\n\n\n\n\n“顺便说一句，我们使用的 Packed 属性确保 clang 不会尝试“字对齐”成员（其中每个成员\xe2\x80\x99 的第一个字节的地址是 4 的倍数），
\nlest we end up with "gaps" in our structs that don\xe2\x80\x99t actually exist on disk."
我不明白有关我们结构中的差距的评论。这是否指的是每个结构之间内存位置的间隙（即，如果是字算法，则每个 3 字节 RGB 之间有一个字节）？为什么这对于优化很重要？
\n\ntypedef uint8_t BYTE;\ntypedef struct\n{\n BYTE rgbtBlue;\n BYTE rgbtGreen;\n BYTE rgbtRed;\n} __attribute__((__packed__))\nRGBTRIPLE;\n当心：偏见的表现！
\n\n如注释中所述，当编译器将填充添加到结构中时，它这样做是为了提高性能。它使用结构元素的对齐方式来提供最佳性能。
\n\n不久前，DEC Alpha 芯片会umr通过执行页面错误、跳转到内核、摆弄字节以获得所需结果并返回正确结果来处理“未对齐的内存请求”( )。与正确对齐的内存请求相比，这是非常慢的；你不惜一切代价避免了这种行为。
如果您进行未对齐的内存访问，其他 RISC 芯片（过去常常）会出现 SIGBUS 错误。即使是英特尔芯片也必须采取一些花哨的措施来处理未对齐的内存访问。
\n\n删除填充的目的是（降低性能，但是）通过能够序列化和反序列化数据而无需“正确”完成工作\xe2\x80\x94，这是一种实际上不起作用的懒惰形式当通信的机器不是同一类型时，正确的序列化应该首先完成。
\n\n我的意思是，如果您通过网络写入数据，通过将结构的内容写入内存块（省略错误检查等）来发送数据似乎更简单：
\n\nwrite(fd, &structure, sizeof(structure));\n接收端可以读取数据：
\n\nread(fd, &structure, sizeof(structure));\n但是，如果计算机类型不同（例如，一台计算机具有 Intel CPU，另一台计算机具有 SPARC 或 Power CPU），则两台计算机对这些结构中数据的解释将有所不同（除非数组的每个元素都是一个char或一个数组char）。为了可靠地转发信息，您必须就字节顺序达成一致（例如，网络字节顺序 \xe2\x80\x94，这在 TCP/IP 网络中是一个非常重要的因素），并且数据应该以约定的方式传输根据命令，以便两端都能理解对方在说什么。
您可以定义其他机制：您可以使用“发送者做出正确的”机制，其中“接收者”让发送者知道它希望如何呈现数据，并且发送者负责修复传输的数据数据。您还可以使用“接收者做出正确的”机制，该机制以相反的方式工作。这两种协议都已在商业上使用\xe2\x80\x94，请参阅DRDA了解此类协议。
\n\nBYTE鉴于is的类型uint8_t，在任何健全的（商业上可行的）编译器中，结构中不会有任何填充。在我看来，这种预防措施是一种幻想或恐惧症，没有现实基础。我当然需要一个仔细记录的反例来相信该属性可以帮助解决实际问题。
\n\n\n我被引导相信，当您将整个结构传递给一个函数时，您可能会遇到问题，就像
\nfread它假设您给它一个像数组一样的内存块，其中没有间隙。如果您的结构有间隙，则第一个字节最终会出现在正确的位置，但接下来的两个字节会写入间隙中，而您没有正确的方法来访问该间隙。
有点……但大多数情况下没有。问题在于填充字节中的值是不确定的。然而，在所示的结构中，我遇到的任何编译器中都不会存在填充；该结构的长度为 3 个字节。没有理由在结构内部（元素之间）或最后一个元素之后的任何位置放置任何填充（并且标准禁止在第一个元素之前填充）。因此，在这种情况下，不存在任何问题。
\n\n如果将二进制数据写入文件并且其中有漏洞，那么您将在漏洞所在的位置写入任意字节值。如果您在同一（类型）机器上回读，实际上不会有问题。如果您在不同（类型）的机器上回读，可能会出现问题 \xe2\x80\x94 因此我对序列化和反序列化的评论。我用 C 语言编程才 30 多年；我从来不需要打包，也不指望这样做。（是的，我已经使用标准布局 \xe2\x80\x94 处理了序列化和反序列化，我主要工作的系统使用了大端数据传输，它对应于网络字节顺序。）
\n| 归档时间： |
|
| 查看次数： |
1968 次 |
| 最近记录： |