Re: How does the Swift Darwin module work?
Re: How does the Swift Darwin module work?
- Subject: Re: How does the Swift Darwin module work?
- From: Roland King <email@hidden>
- Date: Sun, 19 Oct 2014 10:33:12 +0800
>
> That's what I ended up doing (setNonblocking(int inFileDescriptor)), but, I was asking for the sake of learning the language. It would be nice to have generic replacements for fcntl() and ioctl().
>
The best replacement would be to have a set of functions which took the Swiss Army knife which is fcntl() and split it up from fcntl( filedes, cmd, … ) into a series of fnctl_cmd( filedes, typed_argument ) much as Marco suggested. Then you have something which does import nicely into Swift and is typesafe, even the structures are then properly bridged across for you.
Something totally generic would be a c wrapper like this (and I haven’t tested it, just for the sake of discussion)
int fcntl_wrap( int filedes, int cmd, void *arg )
{
return fcntl( filedes, cmd, arg );
}
which bridges into Swift as
func fcntl_wrap(filedes: Int32, cmd: Int32, arg: UnsafeMutablePointer<Void>) -> Int32
You can manipulate that final arg in many very un-typesafe ways to get what you want. If there’s no argument, pass nil, that’s easy. In the case of the F_GETPATH create yourself a buffer of Char or UInt8 or whatever chars are called these days and cast that backwards and forwards.
But see how vile this is, how about F_RDAHEAD, the man page for that says
Turn read ahead off/on. A zero value in arg disables read ahead. A non-zero value in arg turns read ahead on.
that doesn’t actually tell you what ‘arg’ is. Is it a byte, an int, a long, bool .. what? It’s probably an int, but you don’t really know and it’s important, if the function just reads one byte of arg that’s the one needs to be non-zero. So now you have to create a thing which looks like an int but is an UnsafeMutablePointer<Void> so it can be passed into the function
let really_dangerous_variable : UnsafeMutablePointer<Void> = UnsafeMutablePointer( bitPattern:1 )
So that’s how you could do it if you really wanted to, doing so probably means you have a crash in your future.
Marco’s idea of separating out into separate functions per-command and stubbing each into C is a cleaner way of getting something which bridges back into Swift vaguely nicely, and it’s not that much work either, and you can add functions as you need them to a module you write.
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden