> 
> 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 (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Reply via email to