[haiku-bugs] Re: [Haiku] #8568: Make Haiku endian independent
- From: "bonefish" <trac@xxxxxxxxxxxx>
- Date: Thu, 10 May 2012 02:55:28 -0000
#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:
