John had added an open-file wrapper to the open(2) system call, see, or:

(open-file fname flags [perms])    →    fd       (procedure)       POSIX open() 

Perms defaults to #o666. Flags is an integer bitmask, composed by adding together one or more of the following constants: open/read, open/write, open/read+write, open/append, open/create, open/exclusive, open/truncate. It is an error unless exactly one of the open/read, open/write, or open/read+write flags is provided.

Noticing the close-fdes mirror that wraps close(2) suggests we should change the name of one or both.

In and of itself, it's simple, but has implications for associating ports with the resulting file descriptor, some which we've already discussed, more which I'll bring up after implementing open-file in Chibi Scheme, and a bit more thought.

While looking at the total set of flags that POSIX allows to be handed to open(2) ( none of the additional ones really lept out at me as warranting inclusion, except perhaps O_NONBLOCK, which I note is an option in Chibi Scheme's filesystem library.  Per POSIX:

When opening a FIFO with O_RDONLY or O_WRONLY set:

When opening a block special or character special file that supports non-blocking opens:

Otherwise, the O_NONBLOCK flag shall not cause an error, but it is unspecified whether the file status flags will include the O_NONBLOCK flag.

I have no informed opinion on this flag, but adding additional ones is trivial.  Others that might be considered include:

If set, the FD_CLOEXEC flag for the new file descriptor shall be set.

I gather this would be useful for the processes POSIX SRFI, although adding another integer bitmask in a different SRFI, whether in the API or hidden, is also trivial and will interoperate with SRFI-170.

If path names a symbolic link, fail and set errno to [ELOOP].

I'm not sure what serious practical use this has, but since the SRFI is symbolic link aware, perhaps it should be added.

- Harold