Add support for more OpenFileFlags and slightly refactor 'openFd' - #59

Another way could be like the posix-paths module does:
https://github.com/JohnLato/posix-paths/blob/master/src/System/Posix/Directory/Foreign.hsc

which then generates those Flags conveniently from Foreign.hsc into Foreign.hs... this also allows for platform-specific ifdefs.

The open_ function then would look something like this:

open_  :: CString
       -> OpenMode
       -> [Flags]
       -> Maybe FileMode
       -> IO Fd
open_ str how optional_flags maybe_mode = do
    fd <- c_open str all_flags mode_w
    return (Fd fd)
  where
    all_flags  = unionFlags $ optional_flags ++ [open_mode] ++ creat

    (creat, mode_w) = case maybe_mode of
                        Nothing -> ([],0)
                        Just x  -> ([oCreat], x)

    open_mode = case how of
                   ReadOnly  -> oRdonly
                   WriteOnly -> oWronly
                   ReadWrite -> oRdwr

seems there is zero interest?

Busy time of year for many !

Unrelatedly: for our posix apis should we be using closed sums or slowly
moving over to pattern synonyms of the bit masks / flags?

On Wednesday, September 21, 2016, Julian Ospald <[email protected]
javascript:_e(%7B%7D,'cvml','[email protected]');> wrote:

seems there is zero interest?

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#59 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAAQwhS-pmXHZ2k-32S0oSLjMEQKTYZiks5qsWSJgaJpZM4IUKO9
.

@cartazio I'd prefer closed sums for now.

As for the code, I'm on the fence. Its going to break some stuff. Its a matter of whether its worth it. I'd be curious to see what @hvr thinks.

Can some of the developers look into this? Seems like a very useful PR.

No time to maintain this. Developers are not responsive.

@hvr you never gave feedback on this :(

Sorry, totally missed this one. So I see a couple of issues with the current approach; afaik the additional flags (O_NOFOLLOW, O_CLOEXEC, O_DIRECTORY and O_SYNC) were recent additions to the POSIX spec (they weren't yet part of the 2004 edition; they started appearing in the 2016 edition), and I'm not sure about how portable they are, so we may need to account for the possibility they aren't available everywhere.

And this poses the question how to deal when they're not available, and how to signal this to API consumers (c.f. #23) . Another issue is that the representation chosen requires us to make version major bumps whenever we add or remove fields from the OpenFileFlags type. I'd prefer a scheme which avoids that.

That being said, the upcoming unix release already demands a major ver bump, so I think we can do this anyway for now -- assuming we figure out if all our platforms support these new flags (we had trouble recently when adding new terminal mode flags).