Re: EXC_BAD_ACCESS in NSData
Re: EXC_BAD_ACCESS in NSData
- Subject: Re: EXC_BAD_ACCESS in NSData
- From: Charles Srstka <email@hidden>
- Date: Wed, 28 May 2014 23:36:54 -0500
On May 27, 2014, at 3:51 PM, Greg Parker <email@hidden> wrote:
> On May 27, 2014, at 12:52 PM, Charles Srstka <email@hidden> wrote:
>> On May 27, 2014, at 2:08 PM, Greg Parker <email@hidden> wrote:
>>> On May 26, 2014, at 8:28 PM, Charles Srstka <email@hidden> wrote:
>>>> On May 26, 2014, at 7:43 PM, Uli Kusterer <email@hidden> wrote:
>>>>> Regarding endian-swapping, that depends on the file format. If you wrote that file yourself, you don’t usually need to do any swapping.
>>>>
>>>> That's true. For example, back in the PowerPC days, we never had to endian-swap our file formats, because we knew that our file format was created on a Mac, and Macs always used big-endian, and it wasn't as if Apple was ever going to do anything crazy like switch to Intel or anything.
>>>>
>>>> Nowadays, of course, we can be assured that our code will always run on Intel processors, because *obviously* there's no reason your code would ever need to run on something like ARM.
>>>
>>> Note that most ARM platforms are little-endian nowadays, including iOS.
>>>
>>> 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. 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.
>>>
>>> Do you try to handle platforms where arithmetic is not two's-complement or where bytes are not 8 bits? I don't. The Next Big Thing might use them, but that's not the way to bet. Endianness is on the same scale, although admittedly not at that extreme.
>>>
>>> If you're paranoid or you like portability, you should use a reading and writing abstraction that can be changed into an endian transformation if necessary in the future. More than that is unlikely to be worth the investment until you receive a credible threat of an other-endian platform that you care about.
>>
>> I've been bitten by that advice in the past, during the Intel transition. Going through a large codebase trying to find every occurrence where you've transferred data directly to/from a buffer is not fun, and definitely wastes a lot more engineer-hours than properly annotating code as you write it. Writing something like:
>>
>> uint32_t foo = CFSwapInt32LittleToHost(*(uint32_t *)bytes);
>>
>> instead of:
>>
>> uint32_t foo = *(uint32_t *)bytes;
>>
>> scarcely spends "engineer-hours", as it costs nothing more than the 2 seconds taken to type the macro. It's not "untested" per se, since it's doing exactly what it says on the tin; it converts the endianness of the input data to the endianness of the host machine. It just so happens that this time, they're equal, so the macro doesn't have to do anything.
>
> It absolutely is untested. The code is intended to work when the host machine is of either endianness. It has only been executed with one such endianness. The other-endian configuration is untested.
The part that's actually going to be running on the end-user's machine; i.e. the part that I've compiled, is absolutely tested. It reads a value from a file, it turns it into an integer in the host endian (in this case, little endian), and it's completely tested. When I port the code to another platform, that port will obviously need to be tested all over again, as it would *anyway*.
If I were compiling the app for other platforms right now, and then not testing it on the platforms I'd compiled it for, you'd have a point.
Charles
_______________________________________________
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