[haiku-bugs] Re: [Haiku] #8568: Make Haiku endian independent

#8568: Make Haiku endian independent
---------------------------+----------------------------
   Reporter:  jscipione    |      Owner:  nobody
       Type:  enhancement  |     Status:  new
   Priority:  low          |  Milestone:  Unscheduled
  Component:  - General    |    Version:  R1/Development
 Resolution:               |   Keywords:
 Blocked By:               |   Blocking:
Has a Patch:  0            |   Platform:  All
---------------------------+----------------------------

Comment (by bonefish):

 Replying to [ticket:8568 jscipione]:
 > The gist of his technique is this, don't be concerned with the
 endianness of the current host, just pick one, save to your file or write
 to your stream using that endian, then, on the other side, read the same
 endian back.

 Nope, you're misinterpreting his article. The gist is, in Rob's own words:
   There is no reason to ask about local byte order when about to interpret
 an externally provided byte stream.

 > We should be able to eliminate all calls to B_HOST_TO_BENDIAN_INT32 and
 B_BENDIAN_TO_HOST_INT32. Since we are on x86 right now little endian makes
 sense to use, but, in the end it really doesn't matter which you choose.

 I wholeheartedly disagree. We don't control all formats, so we can't just
 assume they all have the same endianess. And as written above, that is not
 what Rob aims at. He just doesn't like code that checks the host
 endianess. And apparently he doesn't seem to have come across preprocessor
 macros and fixed-width types. Comparing his example for converting a
 little endian 32 bit number:
 {{{
 i = (data[0]<<0) | (data[1]<<8) | (data[2]<<16) | (data[3]<<24);
 }}}
 with how it would be done in Haiku
 {{{
 i = B_LENDIAN_TO_HOST_INT32(data);
 }}}
 makes none of his reasons sound very convincing:
   1. It's more code.
 Nope.
   2. It assumes integers are addressable at any byte offset; on some
 machines that's not true.
 Nope, one would read into the appropriate datatype/structure.
   3. It depends on integers being 32 bits long, or requires more #ifdefs
 to pick a 32-bit integer type.
 Nope, since one would use fixed-width types.
   4. It may be a little faster on little-endian machines, but not much,
 and it's slower on big-endian machines.
 It's a no-op on little endian machines. I wouldn't bet on it being slower
 on big endian machines in general. There are architectures that actually
 sport an instruction to swap the byte order.
   5. If you're using a little-endian machine when you write this, there's
 no way to test the big-endian code.
 Yep and there's no need to.
   6. It swaps the bytes, a sure sign of trouble (see below).
 Yeah, sure.

 I may add:
  7. It's more readable, not only because it's shorter, but also because it
 says what it does.


 > This is a low-priority enhancement, not required, but would be nice to
 have.

 Again, I disagree. Neither do I consider it advantageous to remove the
 `*BENDIAN*` macros nor, um, all of the byte order macros.

-- 
Ticket URL: <http://dev.haiku-os.org/ticket/8568#comment:1>
Haiku <http://dev.haiku-os.org>
Haiku - the operating system.

Other related posts: