Thanks for the legwork and entertaining posts on your progress Harold :)
I continue regret that I still can't put more time into this SRFI. I
will join in for real as soon as the GraphQL work plateaus.

> I bring this up because explaining the fiddly details of all of these
> set uid/gid functions, especially the two new ones, with
> set-user-real-and-effective-/gid/ being particularly complicated, is
> looking to get beyond the scope of the SRFI document.

It's probably best to provide dumb wrappers. Unix security has been an
active research area since like 1995. The finer points of things like
uid/gid setting are liable to change in the next decade for many
applications. I don't know of any concrete proposals, but it's not hard
to imagine, especially with containers and capability-based security
frameworks being explored constantly.

> I'm certainly
> being tempted to crib more than I should from the POSIX document, and
> I'm thinking we might want fall back to saying the SRFI's procedures are
> completely straightforward wrappers for these functions.

+1

> All of which
> take integers, even -1 for the -and- functions which means don't change
> that value, and all return 0 or -1 and errno.

I don't think the Scheme wrappers in the SRFI should return integers. Is
there any reason they shouldn't raise an exception and put the errno
value in the exception object?

> documentation, and e.g. Stevens presumably and others who tell you how
> to use them all to do things securely, we'd be covered without trying to
> write some near essay level material for what are from the SRFI's
> viewpoint trivial wrappers.

I agree that detailed explanations are not necessary. They are liable to
change anyway.

More generally, none of the Unix syscalls are useful to regard as
abstractions. One must know exactly what they do. It's not useful, for
example, to think that "write() writes to a file". You have to know
whether the file descriptor is in non-blocking mode, and worry about
EINTR, etc. Basically all of the APIs are like that. What's that quote
about "the expressive power of two dixie cups and a string"... To be
fair to Unix, Windows is hardly any better. Making a portable C-level OS
is just hard.

> And speaking of wrappers, I'm finding the Chibi Scheme automagic C FFI
> marvelous and ideal for a demonstration implementation of this SRFI,

Indeed, it's surprisingly good for a small interpreter.

> only failings of note so far are not being able to pass parameterized
> array sizes, e.g. for user-supplementary-gids, I'm currently doing
>
>> (define-c int (%getgroups getgroups) ((value 65537 int) (result (array
>> gid_t 65537))))

"If gidsetsize is 0, getgroups() shall return the number of group IDs
that it would otherwise return without modifying the array pointed to by
grouplist." [Source:
<https://pubs.opengroup.org/onlinepubs/007904875/functions/getgroups.html>]

Hence two reasonable strategies. First one:

* Call count = getgroups(0, NULL) to get the actual count.
* Then call getgroups(count, gid_array);

Second one:

* Call getgroups() with a reasonable size like 16.
* If you get EINVAL back, call it again, doubling the array size at each
call. All practical situations should be handled with two calls (what
sysadmin makes a system that needs 32 supplementary groups?) but if not,
the powers-of-two growth provides a nice O(log N) safeguard.

> Plus an inability to pass an array of two timespec structs to set file
> times to nanosecond precision, the argument type (array (struct
> timespec) 2) doesn't do the right thing:

I've also dealt with time structs in the Chibi FFI. I just passed four
integers for two (sec, nsec) pairs and combined things on the Scheme
side. It was fine.