<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Sep 23, 2016, at 2:23 PM, Joe Groff <<a href="mailto:jgroff@apple.com" class="">jgroff@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class=""><br class=""><blockquote type="cite" class="">On Sep 23, 2016, at 2:20 PM, Jens Persson <<a href="mailto:jens@bitcycle.com" class="">jens@bitcycle.com</a>> wrote:<br class=""><br class="">What is the difference between:<br class="">ptr.storeBytes(of: x, toByteOffset: offset, as: type(of: x))<br class="">ptr.advanced(by: offset).assumingMemoryBound(to: type(of: x)).pointee = x<br class="">?<br class="">I noticed that the former traps if storing to a misaligned offset while the latter is happy to do that, and I saw it mentioned as a requirement in the documentation, but other than that I'm not sure what would be the pros and cons of using the former / latter?<br class=""></blockquote><br class="">cc'ing Andy, who's the expert on this. AIUI, the former does not semantically bind the memory to the type being stored—informally, it has "memcpy semantics"—whereas the latter *will* bind the memory to a type, which will require all other loads and stores derived from the same pointer to remain of the same type. Neither API officially supports unaligned loads or stores yet; if one crashes and the other doesn't, that's an accident.<br class=""><br class="">-Joe</div></div></blockquote></div><br class=""><div class="">storeBytes(of:as:) is an untyped memory operation. e.g. you could use it store a UInt32 to an Float’s location without binding memory.</div><div class=""><br class=""></div><div class="">assumingMemoryBound(to:) gives you a typed pointer, that you the programmer must guarantee is the correct type for that memory location. If you use this to get a UInt32 pointer into a Float’s location, you get undefined behavior as soon as you access the pointee.</div><div class=""><br class=""></div><div class="">storeBytes traps on misaligned access because memory is being reinterpreted making it easy to violate the alignment precondition.</div><div class=""><br class=""></div><div class="">UnsafePointer<T>.pointee never checked the alignment precondition because normally you wouldn’t need to and it’s supposed to be zero overhead.</div><div class=""><br class=""></div><div class="">assumingMemoryBound(to:) does not check alignment because it isn’t undefined behavior until the pointer is accessed and it’s supposed to be zero overhead.</div><div class=""><br class=""></div><div class="">Basically assumingMemoryBound(to:) is the one backdoor that we have for force casting pointers. The “assuming” should clue the programmer in that they really need to know what they’re doing before using it.</div><div class=""><br class=""></div><div class=""><a href="https://swift.org/migration-guide/se-0107-migrate.html#api-for-binding-memory-types-and-pointer-conversion" class="">https://swift.org/migration-guide/se-0107-migrate.html#api-for-binding-memory-types-and-pointer-conversion</a></div><div class=""><br class=""></div><div class="">-Andy</div></body></html>