Generic C API error SRFI Lassi Kortela 27 Jun 2020 16:16 UTC
> Oops, I knew I'd make that mistake sooner or later > https://en.wikipedia.org/wiki/Lassie). No problem :) >> Since SRFI 198 is very Unix-specific, we should perhaps submit a new >> SRFI about the generic framework. > > I agree, 198 has unique APIs like errno-string (which you propose to > enhance, although that's not 198 API visible), and errno-name, which > gives you the define name, e.g. ENOENT. > >> However, it might be a good idea to take the Windows API (and perhaps >> other OS error APIs) into account in 198. > > Is there any 198 API difference that will be visible besides > errno-name? I'd wager most mature C error APIs conform to this general format: #define MY_ERROR_CODE_FOO 1234 ... const char *my_strerror(int my_error_code); Hence the generic Scheme framework could be like: - Name of C API that caused the error (as a symbol or string) - Name of C constant for the error code (as a symbol or string) - Integer C constant for the error code (as a fixnum) - Which error collection this error came from (as a symbol) - Error message (in English, or a localized one if English not available) - Localized error message (where available) The error collections could be, by convention: - errno or unix (the name "posix" would be misleading) - winapi or windows or win32 - winsock (Windows Sockets errors are different from general WinAPI ones) - sqlite (https://sqlite.org/c3ref/errcode.html) - ... > Which on Windows could just return an empty string, or > maybe something concise that's Windows meaningful? The `errno-name` in SRFI 198 returns the C identifier as a Scheme symbol. WinAPI (and SQLite, etc.) errors also have such C identifiers. It might be enough for SRFI 170 to simply use the generic error framework as-is and give errno/unix as the error collection from which its errors come.