On May 27, 2014, at 3:51 PM, Greg Parker <[email protected]> wrote: > On May 27, 2014, at 12:52 PM, Charles Srstka <[email protected]> wrote: >> On May 27, 2014, at 2:08 PM, Greg Parker <[email protected]> wrote: >>> On May 26, 2014, at 8:28 PM, Charles Srstka <[email protected]> >>> wrote: >>>> On May 26, 2014, at 7:43 PM, Uli Kusterer <[email protected]> >>>> 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 protected]) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [email protected]
