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: Tue, 27 May 2014 14:52:47 -0500
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 also provides a nice parallelism with other pieces of code where you are reading big-endian data, and thus most certainly *do* need to swap, and very importantly, it documents the programmer's intentions.
Suppose you are looking at a chunk of code from a legacy codebase which goes back a large number of years. In this codebase, you see this:
int32_t foo = CFSwapInt32BigToHost(*(uint32_t *)someChunkOfData);
int32_t bar = *(uint32_t *)someOtherChunkOfData;
Does this mean:
a) 'bar' is a later addition to the file format, added some time after the app was ported to Intel, and thus is in little-endian format whereas the older parts of the file are in big-endian (and yes, I've seen formats that do this), or
b) 'bar' is supposed to be in big-endian just like the rest of the file format, and the line was originally added in the PowerPC days, and now it's just a bug that no one's caught yet?
Without explicit annotations, you don't know the answer to this question, but if the original developer had put the appropriate macro in there, you'd know exactly what kind of data s/he intended that line to be reading, and then you'd know how to maintain it in the future.
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