I agree, it's just a lot of work for someone (not me; I will only wrap the
things I need).
> On Oct 18, 2014, at 19:33 , Roland King <r...@rols.org> wrote:
>
>>
>> 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.
>
--
Rick Mann
rm...@latencyzero.com
_______________________________________________
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
