There is no well-defined bijection between ports and fds, is there?

Is an implementation compliant if it just returns #f whenever
port-internal-fd is invoked?

To me, it looks like a leak of a low-level implementation detail when
viewed from the scope of this SRFI.

If bare fds will be needed in the future, doesn't it make sense to put
them in their own SRFI?

Marc

Am Do., 10. Sept. 2020 um 18:22 Uhr schrieb Lassi Kortela <xxxxxx@lassi.io>:
>
> [Harold:]
> > that there are some popular use cases where already having a file
> > descriptor, you prefer operating on it instead of the file name.
>
> +1
>
> [Shiro:]
> > I have a mixed feeling of this.
> > In each specific implementation, non-dup port-fd is definitely a
> > requirement, for it is needed to implement low-level stuff.  However,
> > such code is inevitably implementation-specific.
>
> It's also a very simple procedure. I agree that it's nice to have.
>
> > - Showing port's underlying fd for diagnostic purpose.
>
> +1
>
> > - To pass the fd to other fd->*port, effectively dup()-ing port.  It can
> > be done with duping port->fd, but it saves one intermediate fd.
>
> Sounds like it could be useful in special circumstances. But a generic
> `copy-port` procedure would probably be safer for most uses. It can take
> care that buffering is in sync and other such things.
>
> [Harold:]
> > So while using its result is obviously dangerous, and should be
> > described as such, I think we should keep it in the SRFI 170 API,
> > although I'm not sure about the best name for it.
>
> If we want to emphasize that operating on fd numbers is dangerous, one
> way to do that is just to use longer names:
>
> - port-file-descriptor (just return the existing number)
> - copy-file-descriptor (dup() and dup2())
> - close-file-descriptor (close())