Earlier quoted context omitted.
> 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.
This is true.
The Byte Order Fiasco
221–230 of 378 posts
Re: The Byte Order Fiasco
#222Earlier 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 protocols still mostly use "Network Byte Order", i.e. big endian.
Or text. Or handled by generated code like protobuf.
Re: The Byte Order Fiasco
#223Earlier quoted context omitted.
Really? Apparently the first year students at my university didn't had any issue going from Standard Pascal to C++, in the mid-90's. Proper C++ was taught using our string, vector and collection classes, given that we were still a couple of years away from ISO C++ being fully defined. C style programming with low level tricks were only introduced later as advanced topics. Apparently thousands of students managed to g…
C++ in the mid 90s was a lot simpler than C++ now.
No one obliges you to write C++20 with SFINAE template meta-programming, using classes with CTAD constructors.
Just like no Python newbie is able to master Python 3.9 full language set, standard library, numpy, pandas, django,...
Re: The Byte Order Fiasco
#224If 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.
The fallacy in the article is that anyone should code these functions. There's plenty of public domain libraries that do this correctly.
https://github.com/rustyrussell/ccan/blob/master/ccan/endian...
Re: The Byte Order Fiasco
#225Earlier quoted context omitted.
Well you could bit bang and the 9 bits wouldn't be an issue. (Even if you had a tiny PIC microcontroler just to do that) This is best solvable the closer to the device in question and in the simplest way possible.
The irony is that while a tiny PIC can do bit banging easily, the mighty Pi will struggle with it.
I'm familiar with both, and have Pi's bit-banging at 8MHz. It's not hard-realtime like a PIC though (where I've bitbanged a resistor D2A hung off a dsPIC33 to 17.734475MHz). It's an improvement over the years, but surprisingly little since bit-banging 4MHz Z80's more than 4 decades ago, where resolution was 1 T state (250ns).
Re: The Byte Order Fiasco
#226This 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…
I find you missed the point of the post and the issues described in it. In my estimation, libraries like boost are way too big and way too clever and they create more problems than they solve. Also, they don't make me happy. You're overfocusing on a "problem" that is almost completely irrelevant for most of programming. Big endian is rare to be found (almost no hardware to be found, but some file formats and networki…
Every day I spend futzing around with endianness is a day I'm not solving 'real' problems. These things are a distraction and a complete waste of developer time: It should be solved 'once' and only worried about by people specifically looking to improve on the existing solution. If it can't be handled by a library call, there's something really broken in the language.
(imo, both c and cpp are mainly advocated by people suffering from stockholm syndrome.)
Re: The Byte Order Fiasco
#227Isn't the 'modern' solution to memcpy into a temp and swap the bytes in that? C++ has added/will add std::launder and std::bless to deal with this issue
No, it is to read a byte at a time and turn it into the semantic value for the data structure you are filling in. Like read 128 and then 1 and set the variable to 32769. If u are the author of protobufs then you may run profiling and write the best assembly etc but otherwise no, don’t do it.
Re: The Byte Order Fiasco
#228Ubsan should default on. If people don't like it, then they should be made turn it off with a switch, so at least it's more likely to be run than not run. Could save a huge amount of time debugging when compilers or architecture changes. Without it, I'd say many a programmer would be caught by these subtleties in the standard. Coming from a HW background (Verilog) I'd more naturally default to masking and shifting wh…
There was a blog post and a FOSDEM presentation by (misguided) Gentoo developers a few years ago, and it was retracted, because sanitizers add their own exploitable vulnerabilities due to the way they work.
https://blog.hboeck.de/archives/879-Safer-use-of-C-code-runn...
Re: The Byte Order Fiasco
#229Earlier quoted context omitted.
Sorry I'd rather place my faith in arithmetic rather than someone's API provided the compiler is smart enough to understand the arithmetic and optimize accordingly.
"Someone" here is the same compiler you're trusting to optimize your giant arithmetic expression of the same idea. Your statement is internally inconsistent.
There is a value to keeping it completely clear in your head the difference between a value with arithmetic semantics vs a value with octets in a stream semantics. That thinking will work in all contexts, while the compiler knowledge is limited. The thinking will help you write correct ways to encode data in the URL or into a file being uploaded that your code generates for discord or whatever, in Python, without knowledge of the true endianness of the system the code is running on.
Re: The Byte Order Fiasco
#230Earlier quoted context omitted.
Really? Apparently the first year students at my university didn't had any issue going from Standard Pascal to C++, in the mid-90's. Proper C++ was taught using our string, vector and collection classes, given that we were still a couple of years away from ISO C++ being fully defined. C style programming with low level tricks were only introduced later as advanced topics. Apparently thousands of students managed to g…
Well there's a reason universities switched to Java when teaching algorithms and containers after the 90's. C++ is a weaker abstraction that encourages the kind of curiosity that's going to cause a student's brain to melt the moment they try to figure out how things work and encounter the sorts of demons the coursework hasn't prepared them to face. If I was going to teach it, I'd start with octal machine codes and wo…
US universities maybe, there isn't much Java on my former university learning plan.
The only subjects that went full into Java were distributed computing and compiler design.
And during the last 20 years they already went back into their decision.
I should note that languages like Prolog, ML and Smalltalk were part of the learning subjects as well.
Assembly was part of electronic subjects where design of a pseudo CPU was also part of the themes. So we had our own pseudo Assembly, x86 and MIPS.