[swift-users] Accessing the bundle of the call-site

Jordan Rose jordan_rose at apple.com
Fri Dec 2 17:37:44 CST 2016


> On Dec 2, 2016, at 15:36, Rick Aurbach <rlaurb at 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 <gparker at apple.com <mailto:gparker at 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 <rlaurb at icloud.com <mailto:rlaurb at 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_rose at apple.com <mailto:jordan_rose at 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
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-users/attachments/20161202/e536cfbb/attachment.html>


More information about the swift-users mailing list