> On Dec 2, 2016, at 15:36, Rick Aurbach <[email protected]> wrote:
>
> Greg,
>
> This is looking quite strange, because I didn’t see anything like what I
> expected.
>
> Here’s the code that I’ve been using to test #dsohandle:
>
> public extension String {
>
> public func localized(dsoHandle : UnsafeRawPointer = #dsohandle) {
> var dlInformation : dl_info = dl_info()
> let _ = dladdr(dsoHandle, &dlInformation)
> let path = String(describing: dlInformation.dli_fname!)
^ You asked for a string describing a pointer and you got one. :-) Try
String(cString:) instead.
> let bundle = Bundle(path: path)
> }
> }
>
> which is consistent with the following excerpt from the header file:
>
> /*
> * Structure filled in by dladdr().
> */
> public struct dl_info {
>
> public var dli_fname: UnsafePointer<Int8>! /* Pathname of shared object */
>
> public var dli_fbase: UnsafeMutableRawPointer! /* Base address of shared
> object */
>
> public var dli_sname: UnsafePointer<Int8>! /* Name of nearest symbol */
>
> public var dli_saddr: UnsafeMutableRawPointer! /* Address of nearest
> symbol */
>
> public init()
>
> public init(dli_fname: UnsafePointer<Int8>!, dli_fbase:
> UnsafeMutableRawPointer!, dli_sname: UnsafePointer<Int8>!, dli_saddr:
> UnsafeMutableRawPointer!)
> }
> public typealias Dl_info = dl_info
>
> public func dladdr(_: UnsafeRawPointer!, _: UnsafeMutablePointer<Dl_info>!)
> -> Int32
> /* not POSIX */
>
>
> I would have expected path to look something like a URL. However, here is
> what the debugger says (with a breakpoint on the “let bundle…” line:
>
> <Capto_Annotation.png>
>
> As you can see, dli_fname doesn’t look anything like the “pathname of the
> shared object”. Instead it looks more like the address where it was loaded.
> Which, unfortunately, doesn’t get me any further along.
>
> Thoughts?
>
> Has this gotten hairy (and time consuming) enough that I should handle this
> as a Technical Incident??
>
> Cheers,
>
> Rick Aurbach
>
>> On Dec 2, 2016, at 3:08 PM, Greg Parker <[email protected]
>> <mailto:[email protected]>> wrote:
>>
>> On Darwin #dsohandle points to a Mach-O file header. You can pass that
>> address to dyld but I don't see an easy way to pass it to NSBundle.
>>
>> This might work:
>> 1. Pass #dsohandle to dladdr()
>> 2. Pass the dli_fname returned by dladdr() to NSBundle(path:).
>>
>>
>>> On Dec 2, 2016, at 12:50 PM, Rick Aurbach <[email protected]
>>> <mailto:[email protected]>> wrote:
>>>
>>> Jordan,
>>>
>>> I agree — #dsohandle is, indeed, little known. In fact, I’m having a devil
>>> of a time figuring out what it is and what I can do with it. It is clearly
>>> an UnsafeRawPointer, but to what??
>>>
>>> Can you offer either a reference or a few lines of code that can help me
>>> get the information I need from it? [recall that I want the framework’s
>>> bundle so I can find it’s localized.strings file].
>>>
>>> Cheers,
>>>
>>> Rick Aurbach
>>>
>>>> On Dec 2, 2016, at 12:56 PM, Jordan Rose <[email protected]
>>>> <mailto:[email protected]>> wrote:
>>>>
>>>> On Apple platforms, we'd probably prefer you use the little-known
>>>> #dsoHandle, a magic pointer that's unique to the current dylib. Parsing
>>>> out a module name seems incredibly brittle; the form of #function is not
>>>> guaranteed to be stable or useful across Swift versions.
>>>>
>>>> Jordan
>
>
_______________________________________________
swift-users mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-users
