Email list hosting service & mailing list manager

Bytevectors instead of strings in SRFI 170 Lassi Kortela (02 Aug 2020 19:30 UTC)
Re: Bytevectors instead of strings in SRFI 170 Marc Nieper-Wißkirchen (03 Aug 2020 20:18 UTC)
Re: Bytevectors instead of strings in SRFI 170 John Cowan (03 Aug 2020 21:23 UTC)
Re: Bytevectors instead of strings in SRFI 170 Marc Nieper-Wißkirchen (03 Aug 2020 21:28 UTC)
Re: Bytevectors instead of strings in SRFI 170 Lassi Kortela (03 Aug 2020 21:32 UTC)
Re: Bytevectors instead of strings in SRFI 170 Marc Nieper-Wißkirchen (03 Aug 2020 21:34 UTC)

Bytevectors instead of strings in SRFI 170 Lassi Kortela 02 Aug 2020 19:30 UTC

The following procedures take and return strings:

(read-symlink fname)
(directory-files dir [dotfiles?])
(make-directory-files-generator dir [dotfiles?])
(open-directory dir [dot-files?])
(real-path path)
(create-temp-file [prefix])
(call-with-temporary-filename maker [prefix])
(user-info uid/name)
(group-info gid/name)

I think we should define them so that when bytevectors are given in
place of strings as arguments, strings will be returned as bytevectors
as well. This is what the Python OS APIs do nowadays: for example,
compare os.listdir("/") and os.listdir(b"/"). IIRC they started with
strings only but ran into trouble and had to add the bytes support.

In SRFI 170 (current-directory) is idiosyncratic in that it returns a
string but doesn't take any string argument that we could decide whether
to return a string or a bytevector. Also, Schemes like Gambit and Kawa
have a per-thread current directory which I presume is a string.

I'll provide a `os-current-directory-as-bytevector` procedure in the
upcoming SRFI
<https://misc.lassi.io/2020/srfi-submit/process-state-as-bytevectors.html>.