> On Dec 2, 2016, at 15:36, Rick Aurbach <rla...@icloud.com> 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 <gpar...@apple.com 
>> <mailto:gpar...@apple.com>> 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 <rla...@icloud.com 
>>> <mailto:rla...@icloud.com>> 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 <jordan_r...@apple.com 
>>>> <mailto:jordan_r...@apple.com>> 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
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Reply via email to