The Byte Order Fallacy
commandcenter.blogspot.com
The Byte Order Fallacy
1–10 of 61 posts
Re: The Byte Order Fallacy
#2(2012)
Original thread w/104 comments:
Re: The Byte Order Fallacy
#3TCP/IP is big-endian, which is likely the largest footprint for these concerns.
"htonl, htons, ntohl, ntohs - convert values between host and network byte order"
The cheapest big-endian modern device is a Raspberry Pi running a NetBSD "eb" release, for those who want to test their code.
Re: The Byte Order Fallacy
#4Unless you're dealing with binary data in which case byte order matters very much and if you forget to convert it you're causing a world of pain for someone.
He even has an example where he just pushes the problem off to someone else "if the people at Adobe wrote proper code to encode and decode their files", yeah hope they weren't ignoring byte order issues.
Re: The Byte Order Fallacy
#5Unless you're dealing with binary data in which case byte order matters very much and if you forget to convert it you're causing a world of pain for someone. He even has an example where he just pushes the problem off to someone else "if the people at Adobe wrote proper code to encode and decode their files" , yeah hope they weren't ignoring byte order issues.
[deleted]
Re: The Byte Order Fallacy
#6The byte order matters in all cases where there is i/o, being files, network streams, inter chip communication,... For data that stays on the same processor or for files that are only accessed with the processors of the same endianness, there really is no issue, even when doing bit manipulation.
Re: The Byte Order Fallacy
#7Really except for the networking (including say Bluetooth) nobody is big endian anymore. So how about just don't leak that thing from the network layer.
And do not define any data format to be big endian anymore. Deine it as little endian (do not leave it undefined) and everyone will be happy.
Re: The Byte Order Fallacy
#8TCP/IP is big-endian, which is likely the largest footprint for these concerns. "htonl, htons, ntohl, ntohs - convert values between host and network byte order" The cheapest big-endian modern device is a Raspberry Pi running a NetBSD "eb" release, for those who want to test their code. https://wiki.netbsd.org/ports/evbarm/
Yeah, you deal with order when marshaling stuff on the wire, I haven’t dealt with it much for years, but doing embedded software that used to be in my face a lot.
Re: The Byte Order Fallacy
#9IME, there's one big thing that often keeps my programs from being unaffected by byte order: wanting to quickly splat data structures into and out of files, pipes, and sockets, without having to encode or decode each element one-by-one. The only real way to make this endian-independent is to have byte-swapping accessors for everything when it's ultimately produced or consumed, but adding all the code for that is very tedious in most languages. One can argue that handling endianness is the responsible thing to do, but it just doesn't seem worthwhile when I practially know that no one will ever run my code on a big-endian processor.
Re: The Byte Order Fallacy
#10This is a reasonable way to do things, and I've used it before. However I just used Zig's method here, and like it a lot: https://ziglang.org/documentation/master/std/#std.io.Reader....
Given a reader (file, network, buffers can all be turned into readers), you can call readInt. It takes the type you want, and the endianess of the encoding. It's easy to write, self documents, and it's highly efficient.