Adding new contructors to IOMode to support "don't overwrite if already exists" behavior

Sven Panne svenpanne at gmail.com
Wed Apr 1 06:45:17 UTC 2020


Let's have a look at the POSIX spec for open():
https://pubs.opengroup.org/onlinepubs/9699919799/functions/open.html It
very clearly distinguishes between *2* disjoint sets of flags:

   * You have to use exactly one of O_EXEC, O_RDONLY, O_RDWR, O_SEARCH, and
O_WRONLY.

   * In addition, you can specify any combination of O_APPEND, O_CLOEXEC,
O_CREAT, O_DIRECTORY, O_DSYNC, O_EXCL, O_NOCTTY, O_NOFOLLOW, O_NONBLOCK,
O_RSYNC, O_SYNC, O_TRUNC, and O_TTY_INIT.

Alas, GHC.IO.FD and GHC.IO.IOMode completely ignore this distinction
already and add tons of special cases:

   * They add an ad hoc combination of O_WRONLY and O_APPEND (AppendMode).

   * They leave out O_EXEC and O_SEARCH.

   * They add  an ad hoc boolean flag for non-blocking I/O to openFile,
i.e. pick 1 of the 13 possible additional flags.

   * For some obscure reason, O_NOCTTY is always added.

   * HandleType doesn't reflect the first set of flags.

My proposal is to not make this mess even worse by adding yet another ad
hoc combination, but to think about how to expose these two sets in a sane
way.

I didn't have a look at the Windows counterpart or into all the *nix
variants yet, but I guess that the overlap in the API is quite big. But
even the intersection of all the relevant platforms will very probably have
the distinction between the 2 sets of flags, so we should reflect that in
the Haskell API, too.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20200401/912afbab/attachment.html>


More information about the Libraries mailing list