Problems with FDOs as they are specified in SRFI 170 hga@xxxxxx (11 Sep 2020 13:16 UTC)
Re: Problems with FDOs as they are specified in SRFI 170 Marc Nieper-Wißkirchen (11 Sep 2020 13:58 UTC)
(missing)
Re: Problems with FDOs as they are specified in SRFI 170 Shiro Kawai (12 Sep 2020 19:18 UTC)
Re: Problems with FDOs as they are specified in SRFI 170 Shiro Kawai (12 Sep 2020 22:00 UTC)
Re: Problems with FDOs as they are specified in SRFI 170 Shiro Kawai (17 Sep 2020 05:09 UTC)
Re: Problems with FDOs as they are specified in SRFI 170 Marc Nieper-Wißkirchen (12 Sep 2020 13:04 UTC)
Re: Problems with FDOs as they are specified in SRFI 170 hga@xxxxxx (12 Sep 2020 13:10 UTC)

Re: Problems with FDOs as they are specified in SRFI 170 hga@xxxxxx 12 Sep 2020 13:09 UTC

> From: "Marc Nieper-Wißkirchen" <xxxxxx@nieper-wisskirchen.de>
> Date: Saturday, September 12, 2020 8:04 AM
>
> Am Fr., 11. Sept. 2020 um 22:47 Uhr schrieb John Cowan <xxxxxx@ccil.org>:
>
>> I agree that a fdo-internal-fd is a Good Thing, with the same
>> warnings as port-internal-fdo, and I have added it for the benefit
>> of other SRFIs.
>
> What do you mean by "for the benefit of other SRFIs" exactly? If just
> for the benefit of implementing them, exposing them to the
> user-visible API doesn't look right. Or is a consumer of the final set
> of SRFIs expected to call these procedures?

Not John, but as I see it, if your SRFI 170 emits FDOs that are opaque
disjoint type instead of integers, and you must assume it does for a
portable SRFI, then you must convert FODs to integers for when you
need the real file descriptor.

- Harold