[swift-dev] C Macros and Variadic functions
swift-dev at ryan.lovelett.me
Tue Jan 5 20:41:30 CST 2016
First off thanks for the help.
No doubt I'm doing something wrong. I wish I could help debug my own
problem but I don't really get what @_silgen_name does. That seems like
black magic to me.
That compiled though now it won't link. I've put the code up as a
$ swift build Linking Executable: .build/debug/CastableLive /home/ryan/Source/castable-
live/.build/debug/CastableLive.o/main.swift.o: In function
live/main.swift:40: undefined reference to `ioctl' /usr/bin/ld: /home/ryan/Source/castable-
live/.build/debug/CastableLive: hidden symbol `ioctl' isn't defined
/usr/bin/ld: final link failed: Bad value clang-3.7: error: linker
command failed with exit code 1 (use -v to see invocation) <unknown>:0:
error: link command failed with exit code 1 (use -v to see invocation)
<unknown>:0: error: build had 1 command failures error: exit(1): ["/usr/bin/swift-build-
tool", "-f", "/home/ryan/Source/castable-
On Tue, Jan 5, 2016, at 04:57 PM, Kate Stone wrote:
>> On Jan 5, 2016, at 12:32 PM, Ryan Lovelett via swift-dev <swift-
>> dev at swift.org> wrote:
>> Just to be clear though the intent of my question was not to quibble
>> with compiler error messages. My real question is how are we meant to
>> do systems programming with Swift on Linux if we cannot call ioctl?
> In the absence of an automatic mechanism for importing the definition
> of variadic functions you can still define your own prototypes and
> bind them to the system implementation. For example, this
> @_silgen_name("ioctl") func ioctl(fildes: CInt, request: UInt64,
> result: UnsafePointer<Int>) -> Int
> … gives you a non-variadic interface to ioctl that you can use for
> invocations that conform to this specific convention. You can define
> as many overloads as you wish, and so long as you’re cautious about
> which one you’re using for a given request you should be able to make
> The same basic strategy can be applied to any variadic functional
> interfaces. Ideally you’d want to hide this implementation detail
> behind a more Swift-friendly API where the request type is implied to
> create a more type-safe interface.
> Kate Stonek8stone at apple.com Xcode Low Level Tools
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-dev