Re: Remove file descriptors completely from srfi-170? Lassi Kortela (10 Sep 2020 15:55 UTC)
Re: Remove file descriptors completely from srfi-170? Duy Nguyen (10 Sep 2020 15:59 UTC)
open-file and fd->*port Lassi Kortela (10 Sep 2020 16:05 UTC)
Re: open-file and fd->*port Duy Nguyen (10 Sep 2020 16:16 UTC)
Re: open-file and fd->*port Shiro Kawai (10 Sep 2020 17:34 UTC)
Re: open-file and fd->*port Duy Nguyen (10 Sep 2020 17:41 UTC)
Re: open-file and fd->*port John Cowan (10 Sep 2020 18:19 UTC)

open-file and fd->*port Lassi Kortela 10 Sep 2020 16:05 UTC

>>> Why not combine open-file and
>>> fd->*port in one? All other procedures either take pathname or a port.
>>
>> POSIX open() takes a whole bunch of flags which are relevant when
>> opening a pathname and don't have much to do with converting an
>> already-existing fd to a Scheme port.
>> <https://pubs.opengroup.org/onlinepubs/9699919799/functions/open.html>
>
> So the new open-file also takes a bunch of flags and returns a port.
> Since there's no way for you to get hold of an fd in the first place
> (unless you count on special numbers 0, 1 and 2), converting an
> already-existing fd to a Scheme port is a moot point.

A child process using a known fd number (e.g. 3) from its parent (or
from its predecessor before execve()) is a good convention for IPC.
Hence it ought to be a useful feature to open a known fd as a Scheme port.

If some C API outside SRFI 170 returns an fd, being able to turn that
into a Scheme port is also good.

If open-file takes an integer (giving the fd) how would it interpret its
flags argument?