[swift-users] What is "binding" memory?

[Andrew Trick]

> On Nov 4, 2016, at 12:16 AM, Rien <Rien at Balancingrock.nl> wrote:
> 
> Thanks Any, most informative.
> 
> So the pointer “gateway’s” are in fact ephemeral. That is good for performance.
> 
> As to the low level interfaces, are you aware of any effort that addresses the POSIX socket functions?
> (Things like ‘addrinfo')

I've seen some discussion on mailing lists and forums.  I included a little blurb in the 3.0 migration guide.  Search for socket API helpers in this page. 

https://swift.org/migration-guide/se-0107-migrate.html#common-use-cases

Andy

> 
> Regards,
> Rien
> 
> Site: http://balancingrock.nl
> Blog: http://swiftrien.blogspot.com
> Github: http://github.com/Swiftrien
> Project: http://swiftfire.nl
> 
> 
> 
> 
>>> On 04 Nov 2016, at 06:24, Andrew Trick <atrick at apple.com> wrote:
>>> 
>>> 
>>>> On Nov 3, 2016, at 7:41 AM, Rien via swift-users <swift-users at swift.org> wrote:
>>>> 
>>>> On 03 Nov 2016, at 15:16, Manfred Schubert via swift-users <swift-users at swift.org> wrote:
>>>> 
>>>> 
>>>>> Am 02.11.2016 um 18:37 schrieb Rien <Rien at Balancingrock.nl>:
>>>>> 
>>>>>>> 
>>>>>>> var rawPtr = UnsafeMutableRawPointer.allocate(bytes: 2, alignedTo: 0)
>>>>>>> 
>>>>>>> var widePtr = rawPtr.bindMemory(to: Int16.self, capacity: 1)
>>>>>>> 
>>>>>>> widePtr.pointee = 32
>>>>>>> 
>>>>>>> var narrowPtr = rawPtr.bindMemory(to: UInt8.self, capacity: 2)
>>>>>>> 
>>>>>>> narrowPtr[0] = 16
>>>>>>> narrowPtr[1] = 255
>>>>>>> 
>>>>>>> print(widePtr.pointee)
>>>>>> 
>>>>>> 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?
>>>>> 
>>>>> Why do you think it should not be allowed.
>>>>> AFAICS everything is correct.
>>>> 
>>>> 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.
>>>> 
>>> 
>>> Ah, but that is not the case.
>>> 
>>> It is important to differentiate between the “gateway” to the memory and the memory area itself.
>>> Different programming languages/compilers have different approaches, but I believe that Swift allocates a struct for every gateway.
>>> widePtr and narrowPtr are two different gateways. They refer to different struct's. But the struct for each of them refers to the same memory area.
>> 
>> 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:
>> 
>> func foo<T: Equatable>(rawPtr: UnsafeRawPointer, ptrT: UnsafePointer<T>) {
>>  if rawPtr == UnsafeRawPointer(ptrT) {
>>    assert(rawPtr.assumingMemoryBound(to: T.self).pointee == ptrT.pointee)
>>  }
>> }
>> 
>> Note that assumingMemoryBound(to:) is essentially a nice way of doing unsafeBitCast, but intentional and verifiable.
>> 
>>> 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
>> 
>> Swift strict aliasing means that unrelated typed accesses to memory cannot overlap in their underlying raw memory.
>> 
>> Our UnsafePointer value representation is not realistically ever going to depend on the Pointee type.
>> 
>>> Every access to the raw memory via a gateway must follow the rules for that gateway.
>> 
>>> 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.
>>> 
>>> This is not only very useful, but it also opens the door to better interfaces to some low level Unix APIs.
>> 
>> I think we would want a Swift interface on top of those APIs that doesn’t rely on type punning.
>> 
>> 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.
>> 
>> 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.
>> 
>> -Andy
>> 
>>> 
>>> 
>>>> 
>>>> Manfred
>>>> _______________________________________________
>>>> swift-users mailing list
>>>> swift-users at swift.org
>>>> https://lists.swift.org/mailman/listinfo/swift-users
>>> 
>>> Regards,
>>> Rien
>>> 
>>> Site: http://balancingrock.nl
>>> Blog: http://swiftrien.blogspot.com
>>> Github: http://github.com/Swiftrien
>>> Project: http://swiftfire.nl
>>> 
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> swift-users mailing list
>>> swift-users at swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-users
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-users/attachments/20161104/00f5fcb6/attachment.html>