Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Byte Order Fiasco

justine.lol

Post reply on HN
Print view View original

51–60 of 378 posts

Re: The Byte Order Fiasco

#51

Post by borman »

jart wrote: post #19
rwmj wrote: post #8

If you can assume GCC or Clang then __builtin_bswap{16,32,64} functions are provided which will be considerably more efficient, less error-prone, and easier to use than anything you can homebrew.

That's not true. If you write the byte swap in ANSI C using the gigantic mask+shift expression it'll optimize down to the bswap instruction under both GCC and Clang, as the blog post points out.

Funny that compilers (e.g. clang: https://github.com/llvm/llvm-project/blob/b04148f77713c92ee5... ) might be able to do that only because someone on the compiler team has hand-coded a bswap expression detector.

Re: The Byte Order Fiasco

#53

Post by BenoitEssiambre »

tssva wrote: post #13
pantalaimon wrote: post #9

Earlier quoted context omitted.

The good thing is that Big Endian is pretty much irrelevant these days. Of all the historically Big Endian architectures, s390x is indeed the only one left that has not switched to little endian.

Network byte order is big endian so it is far from being pretty much irrelevant these days.

Also, this might be irrelevant at the cpu level, but within a byte, bits are usually displayed most significant bit first, so with little endian you end up with bit order:

7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8

instead of

15 to 0

This is because little endian is not how humans write numbers. For consistency with little endianness we would have to switch to writing "one hundred and twenty three" as

321

Re: The Byte Order Fiasco

#54

Post by benjohnson »

chrisseaton wrote: post #30
pantalaimon wrote: post #9

Earlier quoted context omitted.

The good thing is that Big Endian is pretty much irrelevant these days. Of all the historically Big Endian architectures, s390x is indeed the only one left that has not switched to little endian.

> The good thing is that Big Endian is pretty much irrelevant these days. This is nonsense - many file formats are big endian.

With a bonus of some being EBCDIC too.

Re: The Byte Order Fiasco

#55

Post by nly »

vladharbuz wrote: post #44
nly wrote: post #23

This is why, in 2021, the mantra that C is a good language for these low level byte twiddling tasks needs to die. Dealing with alignment and endianness properly requires a language that allows you to build abstractions. The following is perfectly well defined in C++, despite looking like almost the same as the original unsafe C: #include #include using namespace boost::endian; unsigned char b[5] = {0x80,0x01,0x02,0x0…

Correct me if I'm wrong, but your example is just using a library to do the same task, rather than illustrating any difference between C and C++. If you want to pull boost in to do this, that's great, but that hardly seems like a fair comparison to the OP, since instead of implementing code to solve this problem yourself you're just importing someone else's code.

No, the fact that this can be done in a library and looks like a native language feature demonstrates the power of C++ as a language.

This example is demonstrating:

- First class treatment of user (or library) defined types

- Operator overloading

- The fact that it produces fast machine code. Try changing big_uint32_t to regular uint32_t to see how this changes. When you use the later ubsan will introduce a trap for runtime checks, but it doesn't need to in this case.

Re: The Byte Order Fiasco

#56

Post by wongarsu »

BlueTemplar wrote: post #36
genmon wrote: post #26

Earlier quoted context omitted.

That reminds me of a project to interface with vending machines. (We built a bookshop in a vending machine that would tweet whenever it sold an item, with automated stock management.) Vending machines have an internal protocol a little like I2C. We created a custom peripheral to bridge the machine to the web, based on a Raspberry Pi. The protocol was defined by Coca Cola Japan in 1975 (in order to have optionality in…

We really should have moved to 32 bit bytes when moving to 64 bit words. Would have simplified Unicode considerably.

People were holding off on transitioning because pointers use twice as much space in x64. If bytes had quadrupled in space with x64 we would still be using 32 bit software everywhere

Re: The Byte Order Fiasco

#57

Post by mannschott »

dataflow wrote: post #40
pabs3 wrote: post #18

I wonder if those macros work with middle-endian systems.

Is this a joke or am I just unaware of any systems out there that are "middle-endian"..?!

Sadly not a joke, but thankfully quite obscure: https://en.wikipedia.org/wiki/Endianness#Middle-endian

Re: The Byte Order Fiasco

#58

Post by nly »

jart wrote: post #46
nly wrote: post #23

This is why, in 2021, the mantra that C is a good language for these low level byte twiddling tasks needs to die. Dealing with alignment and endianness properly requires a language that allows you to build abstractions. The following is perfectly well defined in C++, despite looking like almost the same as the original unsafe C: #include #include using namespace boost::endian; unsigned char b[5] = {0x80,0x01,0x02,0x0…

C is perfect for these problems. I like teaching the endian serialization problem because it broaches so many of the topics that are key to understanding C/C++ in general. Even if we choose to spend the majority of our time plumbing together functions written by better men, it's nice to understand how the language is defined so we could write those functions, even if we don't need to.

For sure, it's a good way to teach that C is insufficient to deal with even the simplest of tasks. Unfortunately teaching has a bad habit of becoming practice, no matter how good the intention.

With regard to teaching C++ specifically I tend to agree with this talk:

CppCon 2015 - Kate Gregory “Stop Teaching C": https://www.youtube.com/watch?v=YnWhqhNdYyk

Re: The Byte Order Fiasco

#59

Post by cygx »

commandersaki wrote: post #47

It wasn't clear to me but what was the undefined behaviour in the naive approach?

Violation of the effective typing rules ('strict aliasing') and a potential violation of alignment requirements of your platform.

Re: The Byte Order Fiasco

#60

Post by jcadam »

metiscus wrote: post #27
jcadam wrote: post #4

A while back I was on a project to port a satellite simulator from SPARC/Solaris to RHEL/x64. The compressed telemetry stream that came from the satellite needed to be in big endian (and that's what the ground station software expected), and the simulator needed to mimic the behavior. This was not a problem for the old SPARC system, which naturally put everything in the correct order without any fuss, but one of the…

If memory serves correctly, ada 2012 and beyond has language level support for this. I was working on porting some code from an aviation platform to run on PC and it was all in ada 2005 so we didn't have the benefit of that available.

Same here, Ada2005 for the port. The simulator was originally written in Ada95. Part of what made it even less fun was the data was highly packed and individual fields crossed byte boundaries (these 5 bits are X, the next 4 bits are Y, etc.) :(
Post reply on HN