Re: [swift-users] Canonical way to cast C structs

[Bouke Haarsma via swift-users]

Thanks for your replies. After looking at the helper code you mentioned, it 
appears that the code in each call will create a mutable copy of a 
sockaddr_storage. That mutable copy is than rebound/casted to whatever type 
requested. While it probably would be safer to use, it introduces extra copying 
overhead as well. The code that I have now (thanks to Quinn’s helper methods):

let address: sockaddr_storage
let family = CFDataGetBytePtr(addressData!).withMemoryRebound(to: 
sockaddr.self, capacity: 1) {
return $0.pointee.sa_family
}
switch family {
case sa_family_t(AF_INET):
(_, address) = sockaddr_storage.fromSockAddr { (sin: inout sockaddr_in) in
sin.sin_family = sa_family_t(AF_INET)
sin.sin_addr = CFDataGetBytePtr(addressData!).withMemoryRebound(to: 
sockaddr_in.self, capacity: 1) {
$0.pointee.sin_addr
}
}
case sa_family_t(AF_INET6):
(_, address) = sockaddr_storage.fromSockAddr { (sin: inout sockaddr_in6) in
sin.sin6_family = sa_family_t(AF_INET6)
sin.sin6_addr = CFDataGetBytePtr(addressData!).withMemoryRebound(to: 
sockaddr_in6.self, capacity: 1) {
$0.pointee.sin6_addr
}
}
default:
return
}

Is this as Swifty as it can get? Is there a way to make it less verbose? The 
problem I see with this code is that the network protocols are still 
special-cased. 

The addressData CFData object is described like this:

> A CFData object holding the contents of a struct sockaddr appropriate for the 
> protocol family of s (struct sockaddr_in or struct sockaddr_in6, for 
> example), identifying the remote address to which s is connected. This value 
> is NULL except for kCFSocketAcceptCallBack and kCFSocketDataCallBack 
> callbacks.


Thanks,
Bouke


> On 14 sep. 2016, at 08:34, Andrew Trick  wrote:
> 
>> 
>> On Sep 12, 2016, at 12:39 PM, Bouke Haarsma via swift-users 
>> mailto:swift-users@swift.org>> wrote:
>> 
>> Sorry for all the pings, but it appears that the code below doesn’t work 
>> after all;
>> 
>>> fatal error: can't unsafeBitCast between types of different sizes
>> 
>> So the question remains on how to perform the casts using Swift?
>> 
>> —
>> Bouke
> 
> Hi Bouke,
> 
> Please see this migration guide:
> https://swift.org/migration-guide/se-0107-migrate.html 
> 
> 
> It explains a few things that are not self-explanatory and includes some 
> helper code for dealing with the socket API.
> 
> Given how your code is structured, I would start with a raw pointer, then 
> replace all the ‘withMemoryRebound’ calls to ‘bindMemory’, and you should be 
> fine:
> 
> var rawSockAddr = UnsafeRawPointer(CFDataGetBytePtr(data))
> 
> switch …
> case …:
>   let ipv4 = rawSockAddr.bindMemory(to: sockaddr_in.self, capacity: 1)
> 
> You might also be able to avoid CFData and use Swift’s Data directly, but any 
> Swifty API you use will encourage you to restructure your code so that 
> pointer access is confined to a closure, like Data.withUnsafeBytes, or 
> UnsafePointer.withMemoryRebound(to:capacity:). You should never return the 
> pointer argument from these closure. The closure taking APIs are designed to 
> keep your data alive while you access it and make sure you’re not mixing 
> pointers of different types to the same memory.
> 
> -Andy
> 
>>> On 12 sep. 2016, at 21:37, Bouke Haarsma >> > wrote:
>>> 
>>> 
>>> Sorry, missed the first line when copying:
>>> 
>>> let generic = unsafeBitCast(CFDataGetBytePtr(data), to: sockaddr.self)
>>> switch generic.sa_family {
>>> case sa_family_t(AF_INET):
>>> let ipv4 = unsafeBitCast(generic, to: sockaddr_in.self)
>>> //...
>>> case sa_family_t(AF_INET6):
>>> let ipv6 = unsafeBitCast(generic, to: sockaddr_in6.self)
>>> //...
>>> default:
>>> //...
>>> }
>>> 
>>> —
>>> Bouke
>>> 
 On 12 sep. 2016, at 21:35, Bouke Haarsma >>> > wrote:
 
 Ah the missing part of the puzzle appears to be unsafeBitCast(:to:), so 
 the Swift version becomes this:
 
 switch generic.sa_family {
 case sa_family_t(AF_INET):
 let ipv4 = unsafeBitCast(generic, to: sockaddr_in.self)
 //...
 case sa_family_t(AF_INET6):
 let ipv6 = unsafeBitCast(generic, to: sockaddr_in6.self)
 //...
 default:
 //...
 }
 
 —
 Bouke
 
> On 12 sep. 2016, at 21:25, Bouke Haarsma  > wrote:
> 
> Hi all,
> 
> Inside my CFSocketCallBack a pointer to a sockaddr is provided wrapped in 
> a CFData structure. The sockaddr could be either a sockaddr_in (IPv4) or 
> sockaddr_in6 (IPv6) struct. In order to discover which struct you’re 
> dealing with, the attribute sa_family can be inspected. In C this would 
> look something like this:
> 
> struct sockaddr_storage sa;
> 
> switch (((sockaddr*)&sa)->sa_family)
> {
> case AF_INET:
>   

Re: [swift-users] Problem calling a C function passing a void** from Swift 3

[Lane Schwartz via swift-users]

Thank you! This, in conjunction with a later call to bindMemory(to:
capacity:), was exactly what I needed.

On Fri, Sep 16, 2016 at 9:47 AM, Quinn "The Eskimo!" via swift-users <
swift-users@swift.org> wrote:

>
> On 15 Sep 2016, at 22:11, Lane Schwartz via swift-users <
> swift-users@swift.org> wrote:
>
> > Can anyone help me get the equivalent functionality in Swift 3?
>
> I think the main issue here is that, in Swift 3, unsafe pointers, in their
> various flavours, don’t explicitly support nil.  Rather, nil is modelled
> like it is for any other type, via `Optional`.  You can read all about this
> change in SE-0055 [1]
>
> So, if you have an C API like this:
>
> extern int HackAlloc(void ** bufPtrPtr, size_t bufSize);
> extern void HackFree(void * bufPtr);
>
> you can call it like this:
>
> var buf: UnsafeMutableRawPointer? = nil
> let result = HackAlloc(&buf, 1024)
> if result == 0 {
> HackFree(buf)
> }
>
> This is very similar to what you currently have except that `buf` is
> explicitly made optional.
>
> The other difference is that `buf` is a ‘raw’ pointer, which means you
> have to understand Swift 3’s type aliasing rules.  You can read about the
> details in SE-0107 [2] bug a good place to start is the “UnsafeRawPointer
> Migration” section of the Swift 3 migration guide.
>
> 
>
> Share and Enjoy
> --
> Quinn "The Eskimo!"
> Apple Developer Relations, Developer Technical Support, Core OS/Hardware
>
> [1]:  proposals/0055-optional-unsafe-pointers.md>
>
> [2]:  unsaferawpointer.md>
>
> ___
> swift-users mailing list
> swift-users@swift.org
> https://lists.swift.org/mailman/listinfo/swift-users
>



-- 
When a place gets crowded enough to require ID's, social collapse is not
far away.  It is time to go elsewhere.  The best thing about space travel
is that it made it possible to go elsewhere.
-- R.A. Heinlein, "Time Enough For Love"
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] How to create an uninitialized pointer in Swift 3

[Lane Schwartz via swift-users]

Thank you so much. That's exactly what I needed!

Lane
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] SPM: Subfolders in a Module

[Toni Suter via swift-users]

Ok, thank you very much!

Best regards
Toni

> Am 16.09.2016 um 07:26 schrieb Ankit Agarwal :
> 
> 
> 
> On Fri, Sep 16, 2016 at 12:21 AM, Toni Suter via swift-users 
> mailto:swift-users@swift.org>> wrote:
> Hi everyone,
> 
> Let's assume there's a Swift package with the following Layout:
> 
> MyPackage/
> ├── Package.swift
> └── Sources
> └── MyModule
> ├── SubFolder
> │   └── MyClass.swift
> └── main.swift
> 
> As far as I can tell, there's still just one module called MyModule and the 
> subfolder doesn't create
> a nested module or something like that. Is that correct? Do only top level 
> folders in the Sources directory
> become modules?
> 
> 
> Yup thats correct, in this case there will be one executable module named 
> `MyModule` with sources being `SubFolder/MyClass.swift` and `main.swift`.
>  
> 
> -- 
> Ankit

___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

[swift-users] open/public protocol with not overridable default implementation in the future?

[Adrian Zubarev via swift-users]

I always wanted a way to make some protocol default implementations not 
overridable. Now Swift 3 got open vs. public behavior for classes. (Hopefully 
the inconsistency will be fixed soon and we’ll get open protocols as well.)

Imagine this scenario with open/public protocols.

// Module A
// `open protocol` means that in a diff. module I'll
// be able to conform to that protocol
open protocol Proto {}

extension Proto {
 // shouldn't this mean that the variable is not overridable  
 // from a different module? :)
 public var foo: Int { return 42 }
}

// Module B
struct A : Proto {
// can I or can I not override `foo` from here?
}
I wonder if my thinking is correct here, or do we need something else to make 
extensions with default implementation to be fixed and not overridable?



-- 
Adrian Zubarev
Sent with Airmail
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] Problem calling a C function passing a void** from Swift 3

[Quinn "The Eskimo!" via swift-users]

On 15 Sep 2016, at 22:11, Lane Schwartz via swift-users  
wrote:

> Can anyone help me get the equivalent functionality in Swift 3?

I think the main issue here is that, in Swift 3, unsafe pointers, in their 
various flavours, don’t explicitly support nil.  Rather, nil is modelled like 
it is for any other type, via `Optional`.  You can read all about this change 
in SE-0055 [1]

So, if you have an C API like this:

extern int HackAlloc(void ** bufPtrPtr, size_t bufSize);
extern void HackFree(void * bufPtr);

you can call it like this:

var buf: UnsafeMutableRawPointer? = nil
let result = HackAlloc(&buf, 1024)
if result == 0 {
HackFree(buf)
}

This is very similar to what you currently have except that `buf` is explicitly 
made optional.

The other difference is that `buf` is a ‘raw’ pointer, which means you have to 
understand Swift 3’s type aliasing rules.  You can read about the details in 
SE-0107 [2] bug a good place to start is the “UnsafeRawPointer Migration” 
section of the Swift 3 migration guide.



Share and Enjoy
--
Quinn "The Eskimo!"
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

[1]: 


[2]: 


___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] Vague error description when trying to match an instance in a switch statement

[Quinn "The Eskimo!" via swift-users]

On 15 Sep 2016, at 19:53, hello--- via swift-users  
wrote:

> It would be nice if the error message could be improved to spare confusion for
> the other developers.

Indeed.  If you can file a bug about this, that’d be grand.



Share and Enjoy
--
Quinn "The Eskimo!"
Apple Developer Relations, Developer Technical Support, Core OS/Hardware


___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] How to create an uninitialized pointer in Swift 3

[Martin R via swift-users]

In Swift 3, COpaquePointer was renamed to OpaquePointer, and nullable pointers 
are represented by optionals:

  SE-0055 – Make unsafe pointer nullability explicit using Optional
  
https://github.com/apple/swift-evolution/blob/master/proposals/0055-optional-unsafe-pointers.md

So the following should work in Swift 3:

  var cublasHandle: OpaquePointer?
  let status = cublasCreate_v2(&cublasHandle)

Martin

> On 15 Sep 2016, at 23:38, Lane Schwartz via swift-users 
>  wrote:
> 
> In Swift 2.2, I could do the following:
> 
> var cublasHandle : COpaquePointer = nil
> let status = cublasCreate_v2(&cublasHandle)
> 
> Where cublasCreate_v2 is a C function that takes a pointer, and then 
> initializes some memory at that address.
> 
> I haven't been able to figure out an equivalent in Swift 3. Any suggestions, 
> especially to documentation, would be greatly appreciated.
> 
> Thanks,
> Lane
> 
> ___
> 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