Strange Behavior When Looking for Hex Values
Strange Behavior When Looking for Hex Values
- Subject: Strange Behavior When Looking for Hex Values
- From: James Kelly <email@hidden>
- Date: Tue, 02 Oct 2007 09:37:31 -0400
- Thread-topic: Strange Behavior When Looking for Hex Values
Well, this behavior is strange to me at least, and my co-workers seem a bit
surprised as well. I'm willing to entertain the idea that we are missing
something fundamental, however (in fact, I'd say that's the only way to
explain this).
I am searching for a series of hex values in a binary file, they are defined
as two Uint32s. On the intel side of the universal binary, they can be
searched for as expected, using a hex editor for example. When looking at
the ppc code, expecting to see the values reversed, we don't find them as
their whole Uint32 selves, but broken up. Interestingly enough, they are
broken into smaller pieces and interwoven with each other. An example would
probably better explain. Say my hex values were as follows (for
simplicity's sake, we'll assume these are already in the ppc byteorder):
0x12345678
0x9ABCDEF0
In the ppc side of the code, the values will be found like so (using 00 to
represent random fill-in values):
12 34 00 00 9A BC 00 00 56 78 00 00 DE F0
So as you can see, the first four hex digits from the first value, then four
unrelated hex digits, then the first four hex digits from the second value,
then four unrelated hex digits, then the last four hex digits from the first
value, and so on.
Is this the way it is supposed to be? Is there anyone who could point me to
a resource to read up on this behavior and similar issues? Thanks in
advance. And I apologize for the verbosity, I just wanted to be clear on
the problem.
Jim
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden