<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 Nov 3, 2016, at 7:41 AM, Rien via swift-users <<a href="mailto:swift-users@swift.org" class="">swift-users@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><blockquote type="cite" class="">On 03 Nov 2016, at 15:16, Manfred Schubert via swift-users <<a href="mailto:swift-users@swift.org" class="">swift-users@swift.org</a>> wrote:<br class=""><br class=""><br class=""><blockquote type="cite" class="">Am 02.11.2016 um 18:37 schrieb Rien <<a href="mailto:Rien@balancingrock.nl" class="">Rien@Balancingrock.nl</a>>:<br class=""><br class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><br class="">var rawPtr = UnsafeMutableRawPointer.allocate(bytes: 2, alignedTo: 0)<br class=""><br class="">var widePtr = rawPtr.bindMemory(to: Int16.self, capacity: 1)<br class=""><br class="">widePtr.pointee = 32<br class=""><br class="">var narrowPtr = rawPtr.bindMemory(to: UInt8.self, capacity: 2)<br class=""><br class="">narrowPtr[0] = 16<br class="">narrowPtr[1] = 255<br class=""><br class="">print(widePtr.pointee)<br class=""></blockquote><br class="">This compiles and runs as expected, but it should not be allowed if I understand things correctly. So shouldn’t it be a compile time error or crash at runtime? If not, what do I get over how it was before where I was casting to a typed pointer?<br class=""></blockquote><br class="">Why do you think it should not be allowed.<br class="">AFAICS everything is correct.<br class=""></blockquote><br class="">If I understand the documentation correctly, this should not be allowed, because it’s not allowed to access memory as different types at the same time. It needs to be „bound“ to the type first, and can only be bound to one type at a time, so all access as another type must be encapsulated within a closure.<br class=""><br class=""></blockquote><div class=""><br class=""></div><div class="">Ah, but that is not the case.</div><div class=""><br class=""></div><div class="">It is important to differentiate between the “gateway” to the memory and the memory area itself.</div><div class="">Different programming languages/compilers have different approaches, but I believe that Swift allocates a struct for every gateway.</div><div class=""><i class="">widePtr</i> and <i class="">narrowPtr</i> are two different gateways. They refer to different struct's. But the struct for each of them refers to the same memory area.</div></div></div></blockquote><div><br class=""></div><div>In the Swift memory model, a pointer value is substitutable with any other pointer of the same value. And for efficiency, pointer values are implemented as addresses. This was an intentional design decision. For example, this is well-defined:</div><div><br class=""></div><div><div>func foo<T: Equatable>(rawPtr: UnsafeRawPointer, ptrT: UnsafePointer<T>) {</div><div> if rawPtr == UnsafeRawPointer(ptrT) {</div><div> assert(rawPtr.assumingMemoryBound(to: T.self).pointee == ptrT.pointee)</div><div> }</div><div>}</div><div class=""><br class=""></div><div class="">Note that assumingMemoryBound(to:) is essentially a nice way of doing unsafeBitCast, but intentional and verifiable.</div></div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">Example: widePtr can be located at address 0x1000, narrowPtr can be allocated at address 0x2000 while the memory area both refer to (the raw memory) can be at address 0x3000</div></div></div></blockquote><div><br class=""></div>Swift strict aliasing means that unrelated typed accesses to memory cannot overlap in their underlying raw memory.</div><div><br class=""></div><div>Our UnsafePointer value representation is not realistically ever going to depend on the Pointee type.</div><div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">Every access to the raw memory via a gateway must follow the rules for that gateway.</div></div></div></blockquote><div><br class=""></div><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">Note: Some compilers may only create ephemeral gateways, but as long as the compiler checks that the acces follows the correct rules, that is not a problem.</div><div class=""><br class=""></div><div class="">This is not only very useful, but it also opens the door to better interfaces to some low level Unix APIs.</div></div></div></blockquote><div><br class=""></div><div>I think we would want a Swift interface on top of those APIs that doesn’t rely on type punning.</div><div><br class=""></div><div>A Swift pointer value itself doesn’t provide a gateway. It is really bindMemory(to:capacity:) or withMemoryRebound(to:capacity:) that control whether typed access is well-defined at some point in the program.</div><div><br class=""></div><div>In native Swift code, interacting with the memory binding APIs will be extremely rare. Type punning is not a “normal” activity outside of use cases like network I/O and binary file formats. In those cases it probably makes more sense to use a raw pointer directly rather than binding memory to a type.</div><div><br class=""></div><div>-Andy</div><br class=""><blockquote type="cite" class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"></div></blockquote><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><br class=""></div><br class=""><blockquote type="cite" class=""><br class="">Manfred<br class="">_______________________________________________<br class="">swift-users mailing list<br class=""><a href="mailto:swift-users@swift.org" class="">swift-users@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-users" class="">https://lists.swift.org/mailman/listinfo/swift-users</a><br class=""></blockquote><br class=""><div class="">
<div style="letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">Regards,</div><div class="">Rien</div><div class=""><br class=""></div><div class="">Site: <a href="http://balancingrock.nl/" class="">http://balancingrock.nl</a></div><div class="">Blog: <a href="http://swiftrien.blogspot.com/" class="">http://swiftrien.blogspot.com</a></div><div class="">Github: <a href="http://github.com/Swiftrien" class="">http://github.com/Swiftrien</a></div><div class="">Project: <a href="http://swiftfire.nl/" class="">http://swiftfire.nl</a></div><div class=""><br class=""></div></div><br class="Apple-interchange-newline"><br class="Apple-interchange-newline">
</div>
<br class=""></div>_______________________________________________<br class="">swift-users mailing list<br class=""><a href="mailto:swift-users@swift.org" class="">swift-users@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-users<br class=""></div></blockquote></div><br class=""></body></html>