Re: EXC_BAD_ACCESS in NSData
Re: EXC_BAD_ACCESS in NSData
- Subject: Re: EXC_BAD_ACCESS in NSData
- From: Jens Alfke <email@hidden>
- Date: Tue, 27 May 2014 14:58:14 -0700
On May 27, 2014, at 12:08 PM, Greg Parker <email@hidden> wrote:
> Untested code is incorrect code. Don't write endian-swapping code that you can't test because you aren't using any other-endian platforms today.
I disagree. There is a strong, longstanding convention for cross-platform binary data formats (file or network) to store numbers in “network byte order” (big-endian). If you write code for x86 or current-day ARM that reads or writes such a format, you _need_ to endian-swap just to implement the format correctly. And if you’re defining a new format, it probably makes sense to follow convention and use big-endian.
If your code interoperates with an existing correct implementation (by reading/writing the same data), you have de facto tested your byte-swapping code. (If you’d forgotten to add some swaps, your code would break because you’d be reading or writing flipped numbers.)
> It's expensive to spend engineer-hours to write endian code that is untested and therefore incorrect, or to write endian code plus endian tests in the fear that you'll need to port to such a platform someday.
If you later need to make the code portable to other-endian architectures, the code that includes endian-swapping is very likely to work, whereas the code that doesn’t is guaranteed not to work. The code without swapping is also going to have to be reviewed carefully to find all the places where the swaps should be added, which could be pretty nightmarish especially if its original author isn’t available anymore.
Your advice is pretty much like advising iOS programmers (pre-2013) to ignore integer and pointer sizes, and just use ‘int’ for everything instead of size_t or uint32_t, because they hadn’t actually tested their code on a 64-bit CPU. People who’d followed that advice would definitely have had a hard time porting their apps to the iPhone 5s.
—Jens
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden