[swift-dev] C Macros and Variadic functions

[Ryan Lovelett]

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
Gist here[1].

$ swift build Linking Executable:  .build/debug/CastableLive /home/ryan/Source/castable-
live/.build/debug/CastableLive.o/main.swift.o: In function
`_TFC12CastableLive6DVBDVRcfT7adapterSi6numberSi_GSqS0__': /home/ryan/Source/castable-
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-
live/.build/debug/CastableLive.o/llbuild.yaml"]

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
> declaration:
>
> @_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
> progress.
>
> 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
>



Links:

  1. https://gist.github.com/anonymous/4861aba2280251fe57c6
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-dev/attachments/20160105/2f4a38bd/attachment.html>