String init from Int8 tuple?


(Rick M) #1

In my C-interop, I have a need to do this a lot:

typedef struct {
    char message[LGS_MAX_MESSAGE_SIZE];
    ...other stuff...
} lgs_result_info_t;

func
callbackFailed(info inInfo: lgs_result_info_t)
{
    var m = inInfo.message // *See note below
    let message: String = withUnsafePointer(to: &m)
    { inArg -> String in
        return String(cString: UnsafeRawPointer(inArg).assumingMemoryBound(to: Int8.self))
    }
    debugLog("Failed: \(message)")
}

I'd like to do something like this:

extension
String
{
    init<T>(withUnsafePointerTo inPtr: T)
    {
        withUnsafePointer(to: &inPtr)
        { inArg in
             init(cString: UnsafeRawPointer(inArg).assumingMemoryBound(to: Int8.self))
        }
    }
}

But I can't get that to compile.

Help is greatly appreciated.

···

---
*I can't pass inInfo directly to withUnsafePointer, because it says "Cannot pass immutable value as inout argument: 'inInfo' is a 'let' constant"

--
Rick Mann
rmann@latencyzero.com


(Quinn “The Eskimo!”) #2

I think you’re working too hard here. Try this:

func callbackFailed(info inInfo: lgs_result_info_t) {
   var m = inInfo.message
   let message = String(cString: &m.0)
   debugLog("Failed: \(message)")
}

Alas, you still need to do the copy in order to take the address of `m`.

Share and Enjoy

···

On 19 Apr 2017, at 02:11, Rick Mann via swift-users <swift-users@swift.org> wrote:

In my C-interop, I have a need to do this a lot:

--
Quinn "The Eskimo!" <http://www.apple.com/developer/>
Apple Developer Relations, Developer Technical Support, Core OS/Hardware


(Martin R) #3

This reminds me of my previous question https://lists.swift.org/pipermail/swift-users/Week-of-Mon-20170220/004841.html

Is that simplified guaranteed to work? The Swift book says that

> As an optimization, when the argument is a value stored at a physical address in memory, the same memory location is used both inside and outside the function body.

but also

> Write your code using the model given by copy-in copy-out, without depending on the call-by-reference optimization, so that it behaves correctly with or without the optimization.

If `tmp.0` is copied to a separate location then `String(cString: &tmp.0)` would not work correctly, or would it?

to which Quinn responded https://lists.swift.org/pipermail/swift-users/Week-of-Mon-20170220/004842.html

Based on a previous conversation I had with the Swift folks about this, yes.

However, I don’t work on the compiler so it’s possible I misunderstood. Perhaps someone from SwiftLand™ will chime in here.

Some authoritative response from SwiftLand™ would be much appreciated.

Regards, Martin

···

On 19. Apr 2017, at 09:16, Quinn The Eskimo! via swift-users <swift-users@swift.org> wrote:

On 19 Apr 2017, at 02:11, Rick Mann via swift-users <swift-users@swift.org> wrote:

In my C-interop, I have a need to do this a lot:

I think you’re working too hard here. Try this:

func callbackFailed(info inInfo: lgs_result_info_t) {
  var m = inInfo.message
  let message = String(cString: &m.0)
  debugLog("Failed: \(message)")
}

Alas, you still need to do the copy in order to take the address of `m`.

Share and Enjoy
--
Quinn "The Eskimo!" <http://www.apple.com/developer/>
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


(Quinn “The Eskimo!”) #4

Some authoritative response from SwiftLand™ would be much appreciated.

I still don’t work on the Swift compiler (-: but I thought I’d share this quote that recently came by on swift-evolution:

···

On 19 Apr 2017, at 09:14, Martin R <martinr448@gmail.com> wrote:

On 17 Apr 2017, at 22:18, Michael Ilseman via swift-evolution <swift-evolution@swift.org> wrote:

It does bake in an ABI assumption that the tuple layout will be contiguous and strided/addressable. Monitor https://bugs.swift.org/browse/SR-3726 for changes here.

<https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170417/035849.html>

Share and Enjoy
--
Quinn "The Eskimo!" <http://www.apple.com/developer/>
Apple Developer Relations, Developer Technical Support, Core OS/Hardware