To be consistent with errno-error, the "procedure" in "(make-syscall-error errno message procedure data)" should be "procedure-name." For further consistency and clarity in the description, it should be mentioned it's a string.
We ought to suggest that the "list of arbitrary objects" includes the arguments handed to the system call.
The suggestion of the second paragraph that you can use it with an errno of zero is interesting, but sufficiently confusing it should be dropped. I can see people thinking, "but the errno is zero?!?!!??" It lacks an errno-error style procedure to craft your own message.
The SRFI is missing my pet feature, the define name of the errno as a string, like "ENOENT" as used in the POSIX standard and system man pages. My justification for putting this into the Chibi Scheme SRFI 170 sample implementation is that it's easy as long as you have an FFI that makes it simple to capture constants, and SRFI 69 or any other hash table style key-value mapping facility. The motivation is that it can be very obnoxious to try to map from the number to the define name in systems like Linux. While OpenBSD for example continues the tradition of Original Formula UNIX of keeping all of these in one file, that's still several steps to look up. Perhaps suggest adding this to the message errno-error string creates??
Copied from the SRFI 170 discussion, here's my preferred syscall-error:message contents and format in English:
open-file: called open: errno/ENOENT: No such file or directory
There's enough moving parts even without the define name that I think it would help to add the above to the SRFI to reify what's required and/or suggested in the message string contents, and a suggestion might help to keep the English versions of it in the same format.
- Harold