<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Dec 11, 2015, at 9:03 AM, Geordie Jay <<a href="mailto:geojay@gmail.com" class="">geojay@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><span id="mailbox-conversation" class=""><div class=""><div style="margin-top: 0px; margin-bottom: 0px; line-height: normal; font-family: '.AppleSystemUIFont'; color: rgb(73, 79, 80);" class="">Hi Joe,</div><div style="margin-top: 0px; margin-bottom: 0px; line-height: normal; font-family: '.AppleSystemUIFont'; color: rgb(73, 79, 80);" class="">I was just commenting on your @_cdecl commit on GitHub but I’ll keep the discussion here.</div><div style="margin-top: 0px; margin-bottom: 0px; line-height: normal; font-family: '.AppleSystemUIFont'; min-height: 17px; color: rgb(73, 79, 80);" class=""><br class=""></div><div style="margin-top: 0px; margin-bottom: 0px; line-height: normal; font-family: '.AppleSystemUIFont'; color: rgb(73, 79, 80);" class="">I was wondering what it is about your implementation that makes it rely on ObjC interop, as you noted. And whether this dependency can be removed for a quick and dirty proof of concept, or whether it’s something more fundamental than that?</div></div></span></div></blockquote><div><br class=""></div><div>It's mostly because that's how the parameter type validation logic I borrowed from @objc works, and I didn't have time to change it. The code for @cdecl has to be refined to support a "C-only" model, or maybe just only require ObjCInterop and 'import Foundation' when ObjC-specific constructs are used.</div><br class=""><blockquote type="cite" class=""><div class=""><span id="mailbox-conversation" class=""><div class=""><div style="margin-top: 0px; margin-bottom: 0px; line-height: normal; font-family: '.AppleSystemUIFont'; min-height: 17px; color: rgb(73, 79, 80);" class=""><br class=""></div><div style="margin-top: 0px; margin-bottom: 0px; line-height: normal; font-family: '.AppleSystemUIFont'; color: rgb(73, 79, 80);" class="">In this (admittedly very simple) example, the author just calls the mangled name from C and appears to get away with it:</div><div style="margin-top: 0px; margin-bottom: 0px; line-height: normal; font-family: '.AppleSystemUIFont'; color: rgb(73, 79, 80);" class=""><a href="http://romain.goyet.com/articles/running_swift_code_on_android/" class="">http://romain.goyet.com/articles/running_swift_code_on_android/</a></div><div style="margin-top: 0px; margin-bottom: 0px; line-height: normal; font-family: '.AppleSystemUIFont'; min-height: 17px; color: rgb(73, 79, 80);" class=""><br class=""></div><div style="margin-top: 0px; margin-bottom: 0px; line-height: normal; font-family: '.AppleSystemUIFont'; color: rgb(73, 79, 80);" class="">Makes me wonder whether the @_silgen_name approach wouldn’t suffice after all for a proof of concept?</div></div></span></div></blockquote><div><br class=""></div><div>They're getting lucky. Swift function ABIs happen to coincide with C function ABIs in some cases, but this can't be relied on, and will probably break soon when we switch over the Swift-specific calling convention in LLVM.</div><div><br class=""></div><div>-Joe</div><br class=""><blockquote type="cite" class=""><div class=""><span id="mailbox-conversation" class=""><div class=""><div style="margin-top: 0px; margin-bottom: 0px; line-height: normal; font-family: '.AppleSystemUIFont'; color: rgb(73, 79, 80);" class="">Best regards,</div><div style="margin-top: 0px; margin-bottom: 0px; line-height: normal; font-family: '.AppleSystemUIFont'; color: rgb(73, 79, 80);" class="">Geordie</div><div style="margin-top: 0px; margin-bottom: 0px; line-height: normal; font-family: '.AppleSystemUIFont'; color: rgb(73, 79, 80);" class=""><br class=""></div><div style="margin-top: 0px; margin-bottom: 0px; line-height: normal; font-family: '.AppleSystemUIFont'; color: rgb(73, 79, 80);" class="">(Joe: apologies for the double up, I’m evidently terrible at mailing lists and hit reply instead of reply all!)</div>
</div></span><br class=""><br class=""><div class="gmail_quote"><p class="">On Fri, Dec 11, 2015 at 5:53 PM, Joe Groff <span dir="ltr" class=""><<a href="mailto:jgroff@apple.com" target="_blank" class="">jgroff@apple.com</a>></span> wrote:<br class=""></p><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><br class="">> On Dec 11, 2015, at 7:13 AM, Douglas Gregor via swift-dev <<a href="mailto:swift-dev@swift.org" class="">swift-dev@swift.org</a>> wrote:
<br class="">>
<br class="">>
<br class="">>> On Dec 11, 2015, at 4:33 AM, Geordie Jay via swift-dev <<a href="mailto:swift-dev@swift.org" class="">swift-dev@swift.org</a>> wrote:
<br class="">>>
<br class="">>> Hi, maybe one of the Apple devs can help out with this quick Q:
<br class="">>>
<br class="">>> To interface with the JNI, we’d presumably need to call swift functions from our compiled swift binaries from C (or directly from Java, the result being the same). Is there a way to demangle certain symbols in the output binary to this effect, or is there another / a better way to access Swift functions from C?
<br class="">>
<br class="">> Others can probably give a more detailed response, but...
<br class="">>
<br class="">> There’s a Swift demangler in Swift’s “Basic” library (lib/Basic/Demangle.cpp), along with a standalone tool (swift-demangle) you can experiment with. The information in the mangled name should be complete enough to call, but you’ll need to match Swift’s calling convention.
<br class="">>
<br class="">> If it’s just a specific set of Swift functions you want to call from C, you can use the @_silgen_name attribute to override the mangled name, and/or make them @convention(c) to use the C calling convention.
<br class=""><br class="">@_silgen_name isn't the right answer here, since the convention will be wrong, and it won't interact properly with Clang imports and exports. Like Slava said, you want something like the '@_cdecl' attribute he proposed and I half-implemented.
<br class=""><br class="">-Joe</blockquote></div><br class=""></div></blockquote></div><br class=""></body></html>