实际应用中依赖于字节序的代码?
我知道以下 C 代码与字节序相关:
short s_endian = 0x4142;
char c_endian = *(char *)&s_endian;
在大字节序机器上,c_endian 将是 'A'(0x41);而在小端机器上,它将是“B”(0x42)。
但这段代码看起来有点难看。那么实际应用中是否存在依赖于字节序的代码呢?或者您是否遇到过在移植到具有不同字节序的不同目标时需要进行大量更改的应用程序?
谢谢。
I know the following C code is endian-dependent:
short s_endian = 0x4142;
char c_endian = *(char *)&s_endian;
On a big-endian machine, c_endian will be 'A'(0x41); while on a little-endian machine, it will be 'B'(0x42).
But this code seems kind of ugly. So is there endian dependent code in real applications? Or have you came across any application that needs a lot of changes when porting to a different target with a different endian?
Thanks.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(6)
几乎所有处理以二进制格式保存超过 8 位整数或通过网络发送此类整数的代码。举一个极其常见的例子,TCP 标头中的许多字段都属于这一类。
Pretty much any code that deals with saving integers with more than 8 bits in binary format, or sends such integers over the network. For one extremely common example, many of the fields in the TCP header fall into this category.
网络代码依赖于字节序(即使在小字节序机器上,它也应该始终以大字节序在网络上传输),因此需要像
htons()
、htonl() 这样的函数
、net/hton.h
中的ntohs()
和ntohl()
允许轻松从主机到网络的转换字节顺序和网络到主机字节顺序。希望这有帮助,
杰森
Networking code is endian dependent (it should always transfer across the network as big-endian, even on a little-endian machine), hence the need for functions like
htons()
,htonl()
,ntohs()
, andntohl()
innet/hton.h
that allow easy conversions from host-to-network byte-order and network-to-host byte-order.Hope this helps,
Jason
我曾经在 PC 上使用专门的 DAQ 卡收集数据,并尝试在 PowerPC mac 上分析该文件。事实证明,所使用的“文件格式”是原始内存转储...
x86 上的小端字节序,Power PC 上的大端字节序。你弄清楚了。
I once collected data using a specialized DAQ card on a PC, and tried to analyze the file on a PowerPC mac. Turns out the "file format" the thing used was a raw memory dump...
Little endian on x86, big endian on Power PC. You figure it out.
简短的回答是肯定的。任何将原始二进制文件读取/写入文件或套接字的操作都需要跟踪数据的字节顺序。
例如,IP 协议需要大端表示。
The short answer is yes. Anything that reads/writes raw binary to a file or socket needs to keep track of the endianness of the data.
For example, the IP protocol requires big-endian representation.
当操作浮点数的内部表示时,您可以使用整数类型访问部分(或完整值)。例如:
When manipulating the internal representation of floating-point numbers, you could access the parts (or the full value) using an integer type. For example:
如果您的程序将数据发送到另一个系统(通过串行或网络链接,或者将其保存到文件以供其他程序读取)或从另一个系统读取数据,那么您可能会遇到字节序问题。
我不知道静态分析是否能够检测到此类结构,但是让程序员遵循编码标准(其中标记结构元素和变量以指示其字节序)可能会有所帮助。
例如,如果所有网络数据结构都将
_be
附加到多字节成员的命名中,则您可以查找分配了无后缀(主机字节顺序)变量甚至文字值的实例(如 0x1234)到这些成员之一。如果我们能够捕获数据类型中的字节序——uint32_be 和 uint32_le 来与 uint32_t 配合使用,那就太好了。然后编译器可能不允许两者之间的赋值或操作。
htobe32
的签名为uint32_be htobe32( uint32_t n);
。If your program sends data to another system (either over a serial or network link, or by saving it to a file for something else to read) or reads data from another system, then you can have endianness issues.
I don't know that static analysis would be able to detect such constructs, but having your programmers follow a coding standard, where structure elements and variables were marked up to indicate their endianness could help.
For example, if all network data structures had
_be
appended to the named of multi-byte members, you could look for instances where you assigned a non-suffixed (host byte order) variable or even a literal value (like 0x1234) to one of those members.It would be great if we could capture endianness in our datatypes -- uint32_be and uint32_le to go with uint32_t. Then the compiler could disallow assignments or operations between the two. And the signature for
htobe32
would beuint32_be htobe32( uint32_t n);
.