> On Jun 26, 2017, at 12:58 PM, Joe Groff <jgr...@apple.com> wrote: > >> >> On Jun 26, 2017, at 10:20 AM, Charles Srstka via swift-users >> <swift-users@swift.org <mailto:swift-users@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. Charles
_______________________________________________ swift-users mailing list swift-users@swift.org https://lists.swift.org/mailman/listinfo/swift-users
