[swift-users] Extracting arbitrary types (e.g. UInt16) out of Data

Charles Srstka cocoadev at charlessoft.com
Mon Jun 26 13:09:20 CDT 2017

> On Jun 26, 2017, at 12:58 PM, Joe Groff <jgroff at apple.com> wrote:
>> On Jun 26, 2017, at 10:20 AM, Charles Srstka via swift-users <swift-users at swift.org <mailto:swift-users at swift.org>> wrote:
>> Rats, I was hoping that one of the reasons about being so explicit what we’re going to access and where with bindMemory() and friends would be to take care of these sorts of issues.
> There are restrictions that unfortunately prevent unaligned memory support from being the pervasive default; particularly, we want typed pointers to be able to "toll-free-bridge" with typed C pointers, and C also requires well-alignedness of typed memory accesses. Swift's runtime generics model also means that unspecialized code would be using value witness functions to load/store values from memory, and the value witness functions are compiled to assume alignment of their arguments. It would be reasonable for us to add load/storeUnaligned APIs to the RawPointer types that explicitly did unaligned operations; these would however have to be restricted to working only on trivial types that don't require reference counting.
> -Joe

Restricting it to trivial types wouldn’t be bad at all, since stuff you’re reading/writing from raw data is generally going to be either 1) trivial types, or 2) Codable types whose encode/decode routines are usually going to read and write a bunch of... trivial types.

Just reading a whole struct as a chunk of memory has never seemed like a good idea to me, if for no other reason than that it’ll only work if the data happens to be in the same endian order as the host.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-users/attachments/20170626/b5240ab0/attachment.html>

More information about the swift-users mailing list