Re: Does NSData rearrange the order of bits?
Your log messages show that the NSData's bytes are stored completely correctly,
you're just interpreting it incorrectly.
NSData's description method will list the bytes in order, so you see
510600f0. On the other hand, you used the %x format specifier to create your
string, which will print the first byte last, so you get f651. That's
exactly the same infomation-wise, the order of bytes is just flipped.
If you want to create an NSString from the bytes of an NSData where the lower
bytes are ordered first, you can use this:
NSUInteger len = [theToken length];
const unsigned char *bytes = [theToken bytes];
NSMutableString *tokenStr = [NSMutableString stringWithCapacity:len*2];
for (NSUInteger i = 0; i len; ++i) {
[tokenStr appendFormat:@%02x, bytes[i]];
}
- Bryan
(Original reply to Brad directly resubmitted to list at request)
On Nov 30, 2009, at 2:27:55 PM, Brad Gibbs wrote:
Hi,
I'm doing bit-packing via a C function. Logging the bits of the C function
shows the expected result. If I create a string with a hex value format, I
get the correct hex string, but, if I try to put the bytes into an NSData
object with [NSData dataWithBytes: length], the order of the bits changes.
All of the right elements are there, but they're in the wrong order (target
data should be f651, as shown in the Target string is ... log).
My code:
// get the target int from the text field
unsigned int tgtValue = [self.tgtTF intValue];
// use the target int and type to pack the bits into an int
uint32_t tgtBinary = setAnalogValueForIndex(cid, tgtValue);
NSString *tgtString = [NSString stringWithFormat:@%x, tgtBinary];
NSData *tgtData = [NSData dataWithBytes: tgtBinary length:
sizeof(tgtBinary)];
NSLog(@Target data is %...@. Target string is %@, tgtData,
tgtString);
The logs:
011001010001
2009-11-30 11:02:26.126 CertTest[11959:a0f] Target data is 510600f0.
Target string is f651
2009-11-30 11:02:26.204 CertTest[11959:a0f] After adding target, cmdData is
510600f0
If NSData is rearranging the bits, is there some way to prevent this?
Thanks.
Brad
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/bryanhenry%40mac.com
This email sent to bryanhe...@mac.com
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Does NSData rearrange the order of bits?
On 30 Nov 2009, at 20:32, Brad Gibbs wrote: Another list member mailed me an explanation offline, causing me to look for and find the real problem preventing my code from running. Any chance of posting the off list response back to the list? It would improve the usefulness of the list archives (unless the person replied off list because the reply was off topic) to have a complete record of all the answers to your query. __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __ ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Does NSData rearrange the order of bits?
Hi, I'm doing bit-packing via a C function. Logging the bits of the C function shows the expected result. If I create a string with a hex value format, I get the correct hex string, but, if I try to put the bytes into an NSData object with [NSData dataWithBytes: length], the order of the bits changes. All of the right elements are there, but they're in the wrong order (target data should be f651, as shown in the Target string is ... log). My code: // get the target int from the text field unsigned int tgtValue = [self.tgtTF intValue]; // use the target int and type to pack the bits into an int uint32_t tgtBinary = setAnalogValueForIndex(cid, tgtValue); NSString *tgtString = [NSString stringWithFormat:@%x, tgtBinary]; NSData *tgtData = [NSData dataWithBytes: tgtBinary length: sizeof(tgtBinary)]; NSLog(@Target data is %...@. Target string is %@, tgtData, tgtString); The logs: 011001010001 2009-11-30 11:02:26.126 CertTest[11959:a0f] Target data is 510600f0. Target string is f651 2009-11-30 11:02:26.204 CertTest[11959:a0f] After adding target, cmdData is 510600f0 If NSData is rearranging the bits, is there some way to prevent this? Thanks. Brad ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Does NSData rearrange the order of bits?
On Nov 30, 2009, at 11:27 AM, Brad Gibbs wrote: I'm doing bit-packing via a C function. Logging the bits of the C function shows the expected result. If I create a string with a hex value format, I get the correct hex string, but, if I try to put the bytes into an NSData object with [NSData dataWithBytes: length], the order of the bits changes. All of the right elements are there, but they're in the wrong order (target data should be f651, as shown in the Target string is ... log). ... 2009-11-30 11:02:26.126 CertTest[11959:a0f] Target data is 510600f0. Target string is f651 Isn't this the expected byte ordering for a little-endian CPU like x86? The least-significant byte of an integer appears first. —Jens___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Does NSData rearrange the order of bits?
I guess it is. I had another issue that was preventing the code from working properly. Another list member mailed me an explanation offline, causing me to look for and find the real problem preventing my code from running. Thanks for the response. On Nov 30, 2009, at 12:22 PM, Jens Alfke wrote: On Nov 30, 2009, at 11:27 AM, Brad Gibbs wrote: I'm doing bit-packing via a C function. Logging the bits of the C function shows the expected result. If I create a string with a hex value format, I get the correct hex string, but, if I try to put the bytes into an NSData object with [NSData dataWithBytes: length], the order of the bits changes. All of the right elements are there, but they're in the wrong order (target data should be f651, as shown in the Target string is ... log). ... 2009-11-30 11:02:26.126 CertTest[11959:a0f] Target data is 510600f0. Target string is f651 Isn't this the expected byte ordering for a little-endian CPU like x86? The least-significant byte of an integer appears first. —Jens ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Does NSData rearrange the order of bits?
On Nov 30, 2009, at 11:27 AM, Brad Gibbs wrote: Hi, I'm doing bit-packing via a C function. Logging the bits of the C function shows the expected result. If I create a string with a hex value format, I get the correct hex string, but, if I try to put the bytes into an NSData object with [NSData dataWithBytes: length], the order of the bits changes. All of the right elements are there, but they're in the wrong order (target data should be f651, as shown in the Target string is ... log). The output looks correct to me. In particular: [...] NSString *tgtString = [NSString stringWithFormat:@%x, tgtBinary]; Here (above), you ask NSString to interpret the bytes passed as a single integer value as exactly that: an integer value, formatted as hexadecimal. NSData *tgtData = [NSData dataWithBytes: tgtBinary length: sizeof(tgtBinary)]; But here (above), you as NSData to interpret the bytes passed as a sequence of bytes, in the order in which they appear in memory. Presumably you are executing this code on an Intel Mac, where the byte ordering is little-endian. This means the least-significant byte appears first in memory order. So, that's the order you see when you get NSData to produce a string of the bytes it contains. [...] If NSData is rearranging the bits, is there some way to prevent this? To me, a more interesting question is: do you really need some way to prevent this? What exactly are you doing with the NSData later, and why is it important to you that the byte order be some specific endianness? If you really need control over endianness, you can use the Core Endian API (http://developer.apple.com/mac/library/documentation/Carbon/Reference/CoreEndianReference/ ) to always make sure the bytes are of some particular endianness regardless of the computer's native format. But it may be that the endianness doesn't matter. You should be sure you know the difference, and what applies to your own code. Pete ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
