site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com Thread-index: AcgE+WGMoBGBjHDsEdyz+wADk61ysg== Thread-topic: Strange Behavior When Looking for Hex Values User-agent: Microsoft-Entourage/11.3.6.070618 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 (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.appl... This email sent to site_archiver@lists.apple.com