Interesting discussion! I actually ran into rob's post when I was chasing down some problems in coreboot in 2013.
A very experienced OS guy wrote code to manipulate ELF and other such files, and did the common ntohl/htonl thing, and (in one case) got it backwards, and (in another case) forgot to use them. The code all worked just fine on x86 for years, broke on other things, and serialized data in a manner that worked by pure luck -- until we went multiarchitecture again. I think the key sentence is here: "Whenever I see code that asks what the native byte order is, it's almost certain the code is either wrong or misguided." [note: almost certain. Nothing's absolute.] That has been my experience too, but I had not thought about it in quite those terms until I ran across that post. To fix the coreboot problem, I wrote a little conversion library based on the principles laid out in that post and things got fixed.Nobody does open coding; they use the library. But the functions in that library are dead simple because they use these techniques. And, when we add a new architecture, as we've done 4 times now in 3 years, no new library code need be written, and nothing changes. That's nice. I don't have to add new #ifdef cases and so on. The same code just compiles and works correctly. Thinking consciously about endian-ness gets messy, as does optimizing alignment and word size cases by hand. People make mistakes and they're not always easy to catch. The technique he suggests is portable; endian, word size, and alignment neutral; and very easy to read -- no cpp #ifdef stuff needed, just one simple function. You get to use the same code for all architectures. And, big bonus, on good compilers, there's no penalty. At the same time, as always, there's lots of room for disagreement for good reasons. That's what makes horse races :-) ron -- You received this message because you are subscribed to the Google Groups "Akaros" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. For more options, visit https://groups.google.com/d/optout.
