John had added an open-file wrapper to the open(2) system call, see https://github.com/hga/srfi-170, 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) (https://pubs.opengroup.org/onlinepubs/9699919799/functions/open.html) 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:

O_NONBLOCK
When opening a FIFO with O_RDONLY or O_WRONLY set:
If O_NONBLOCK is set, an open() for reading-only shall return without delay. An open() for writing-only shall return an error if no process currently has the file open for reading.
If O_NONBLOCK is clear, an open() for reading-only shall block the calling thread until a thread opens the file for writing. An open() for writing-only shall block the calling thread until a thread opens the file for reading.
When opening a block special or character special file that supports non-blocking opens:
If O_NONBLOCK is set, the open() function shall return without blocking for the device to be ready or available. Subsequent behavior of the device is device-specific.
If O_NONBLOCK is clear, the open() function shall block the calling thread until the device is ready or available before returning.
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:

O_CLOEXEC
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.

O_NOFOLLOW
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