> On Nov 4, 2016, at 12:16 AM, Rien <r...@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 <atr...@apple.com> wrote: >>> >>> >>>> On Nov 3, 2016, at 7:41 AM, Rien via swift-users <swift-users@swift.org> >>>> wrote: >>>> >>>> On 03 Nov 2016, at 15:16, Manfred Schubert via swift-users >>>> <swift-users@swift.org> wrote: >>>> >>>> >>>>> Am 02.11.2016 um 18:37 schrieb Rien <r...@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@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@swift.org >>> https://lists.swift.org/mailman/listinfo/swift-users >
_______________________________________________ swift-users mailing list swift-users@swift.org https://lists.swift.org/mailman/listinfo/swift-users
