From: Jim Rees <xxxxxx@gmail.com>
Date: Saturday, August 01, 2020 8:51 AM

The sample implementation for parse-gecos replaces @'s with the fullname, but it's supposed to be ampersand (&).

Thanks for the catch, it's been fixed in my repo: https://github.com/hga/srfi-170

The spec makes it clear for non-errno-based error, a foreign-error with :code & :foreign-interface set to #f, and :error-set is 'error.   All other details of the exception are left to the implementation.   In the case of user-info and group-info, the underlying posix calls return NULL without an error, therefore one of these is raised.  I feel like the case of "not found" needs more specific treatment.   It's a case common enough in programming (ls prints the uid/gid numeric value if there is no associated user/group, for example), but this specification provides no means to portably distinguish this case from other possible non-errno errors.   What I am suggesting is the addition of a user/group-not-found-error? predicate to the SRFI.

We can say that POSIX doesn't consider this to be an error condition; the text for getpwuid in https://pubs.opengroup.org/onlinepubs/9699919799/functions/getpwuid.html includes:

Applications wishing to check for error situations should set errno to 0 before calling getpwuid(). If getpwuid() returns a null pointer and errno is set to non-zero, an error occurred.

And:

A null pointer shall be returned if the requested entry is not found, or an error occurs. If the requested entry was not found, errno shall not be changed. On error, errno shall be set to indicate the error.

And while text for getpwuid_r is not as clear, and see Issue 6 at the bottom, but implies to me about the same thing.  It's definitely not unheard of when restoring archives to get bogus for the system user and group ids, we should consider not raising an error and have the procedures return #f instead of returning a user-/group-info record.

- Harold