From: John Cowan <xxxxxx@ccil.org>
Date: Friday, November 22, 2019 12:33 PM

On Fri, Nov 22, 2019 at 12:04 PM <xxxxxx@ancell-ent.com> wrote:

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

They aren't all that symmetrical. Open-file can only open a resource with a name in the filesystem, whereas close-fdes can close any fd. It's undefined what happens if you close a fdes that's part of a Scheme port, but some other SRFIs might need to deal in fd's, particularly the process SRFI.

As I was implementing open-file in Chibi-Scheme (done, branch srfi-170-new of https://github.com/hga/chibi-scheme), I saw the same things and agree. The only remaining argument for mirroring is that the system calls are mirrored in a sense, but that's in part because there was such a high premium in the early days of UNIX in reducing characters to be typed and printed at 110 baud. Which is what gave us the most infamous to this day examples in the creat call that lead to the O_CREAT flag used by open-file with a friendlier name.

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

This will take some thought. It can't just be passed through blindly, because in a green-threads Scheme it would block the whole process.

Include a warning? Perhaps or also in Issues??

[ O_CLOEXEC isn't needed or wanted. ]

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.

Perhaps it should.

I can't see any way it's harmful besides a minuscule increase in the API surface; I'll add it soon if no one objects.

- Harold