3 ms·

Exposing a c function from an objective-c file, and then calling into our swift code from there is what we've been doing since before this feature was enabled.

Exposing a c function from an objective-c file, and then calling into our swift code from there is what we've been doing since before this feature was enabled. That of course also requires the Objective C runtime, but we haven't changed to @_cdecl mainly because I'm more worried about the behavior changing than I am about anyone trying to run our swift code on Linux. Assigning a block to a c function pointer is an interesting alternative, I thought we tried something like that but I can't remember now. Hopefully @_cdecl will become a documented and supported feature.

masklinn 10y ago
Does @_cdecl mean "default C calling convention for the platform" or does it actually mean CDECL? How does that work on 64b systems?
- kinofcain 10y ago
  My guess is the former since there aren't any 32 bit Apple platforms anymore.
- ewmailing 10y ago
  I believe it is the calling convention. When I use it, if you look at the symbols/name mangling, what gets generated looks like a C symbol. 000061b4 T BlurrrSwiftEntry vs. 000061cc T _TF1MySDLMainActivity16BlurrrSwiftEntryFT_T_
  - helge5 10y ago
    Well, yes, but I'm unsure why you think that the calling convention has anything to do with the mangled name. That is just a name after all. The name above is the name used to link the functions. The calling convention says how such functions end up being called and is directly represented by the machine code the compiler generates. For example, in which registers arguments are passed, or whether they are passed on the stack and in which order, etc. The C `__cdecl` traditionally just specifies the calling convention, not the link name which is specified by `extern C`. Looks like the Swift `@_cdecl` combines the two. I think in contrast the `@_silgen_name` just specified the link name and not the calling convention. (the result is exactly the same like your example). This is precisely the issue with using `@_silgen_name` - you have to be lucky that calling conventions happen to be the same for simple setups, like `(Void)->Void` or `(OpaquePointer!)->Void` - which seems to be the case at the moment. https://msdn.microsoft.com/de-de/library/zkwh89ks(v=vs.80).aspx https://msdn.microsoft.com/de-de/library/zkwh89ks(v=vs.80).a... P.S.: I'm unsure why anyone would think that this has anything to do with the Objective-C runtime. I guess it may if you pass any kind of ARC objects.
    - kinofcain 10y ago
      "P.S.: I'm unsure why anyone would think that this has anything to do with the Objective-C runtime. I guess it may if you pass any kind of ARC objects." Because the comment on the commit that adds this to the swift source states that "It relies on ObjC interop". https://github.com/apple/swift/commit/013aad13d4245a012cfb762b7edccf92013b3609 https://github.com/apple/swift/commit/013aad13d4245a012cfb76... So maybe not the runtime, per se, but haven't looked into what it's actually generating.

masklinn 10y ago

Does @_cdecl mean "default C calling convention for the platform" or does it actually mean CDECL? How does that work on 64b systems?

kinofcain 10y ago
My guess is the former since there aren't any 32 bit Apple platforms anymore.
ewmailing 10y ago
I believe it is the calling convention. When I use it, if you look at the symbols/name mangling, what gets generated looks like a C symbol. 000061b4 T BlurrrSwiftEntry vs. 000061cc T _TF1MySDLMainActivity16BlurrrSwiftEntryFT_T_
- helge5 10y ago
  Well, yes, but I'm unsure why you think that the calling convention has anything to do with the mangled name. That is just a name after all. The name above is the name used to link the functions. The calling convention says how such functions end up being called and is directly represented by the machine code the compiler generates. For example, in which registers arguments are passed, or whether they are passed on the stack and in which order, etc. The C `__cdecl` traditionally just specifies the calling convention, not the link name which is specified by `extern C`. Looks like the Swift `@_cdecl` combines the two. I think in contrast the `@_silgen_name` just specified the link name and not the calling convention. (the result is exactly the same like your example). This is precisely the issue with using `@_silgen_name` - you have to be lucky that calling conventions happen to be the same for simple setups, like `(Void)->Void` or `(OpaquePointer!)->Void` - which seems to be the case at the moment. https://msdn.microsoft.com/de-de/library/zkwh89ks(v=vs.80).aspx https://msdn.microsoft.com/de-de/library/zkwh89ks(v=vs.80).a... P.S.: I'm unsure why anyone would think that this has anything to do with the Objective-C runtime. I guess it may if you pass any kind of ARC objects.
  - kinofcain 10y ago
    "P.S.: I'm unsure why anyone would think that this has anything to do with the Objective-C runtime. I guess it may if you pass any kind of ARC objects." Because the comment on the commit that adds this to the swift source states that "It relies on ObjC interop". https://github.com/apple/swift/commit/013aad13d4245a012cfb762b7edccf92013b3609 https://github.com/apple/swift/commit/013aad13d4245a012cfb76... So maybe not the runtime, per se, but haven't looked into what it's actually generating.