Final review of johnwcowan/srfi-170/srfi-170.html, part 1 through 3.3 File system temp-file-prefix hga@xxxxxx 13 Aug 2020 15:59 UTC
Re: Final review of johnwcowan/srfi-170/srfi-170.html, part 1 through 3.3 File system temp-file-prefix John Cowan 13 Aug 2020 18:18 UTC
On POSIX errnos using 'number as a key, and SRFI 198 not defining that, 'code, etc. as standards at its level hga@xxxxxx 13 Aug 2020 18:46 UTC
Re: On POSIX errnos using 'number as a key, and SRFI 198 not defining that, 'code, etc. as standards at its level John Cowan 13 Aug 2020 20:31 UTC
Re: On POSIX errnos using 'number as a key, and SRFI 198 not defining that, 'code, etc. as standards at its level hga@xxxxxx 13 Aug 2020 21:04 UTC
Clearing up confusion Lassi Kortela 14 Aug 2020 15:12 UTC
Re: Clearing up confusion, and Windows errors as POSIX errno's Lassi Kortela 14 Aug 2020 15:27 UTC
Re: Clearing up confusion, and Windows errors as POSIX errno's hga@xxxxxx 15 Aug 2020 16:50 UTC
Re: Clearing up confusion John Cowan 15 Aug 2020 00:54 UTC
Re: Clearing up confusion Marc Nieper-Wi├čkirchen 15 Aug 2020 10:46 UTC
Clearing up the previous clearing up Lassi Kortela 15 Aug 2020 11:46 UTC
Re: Clearing up the previous clearing up John Cowan 15 Aug 2020 15:03 UTC
Re: Final review of johnwcowan/srfi-170/srfi-170.html, part 1 through 3.3 File system temp-file-prefix hga@xxxxxx 14 Aug 2020 11:31 UTC
Re: Final review of johnwcowan/srfi-170/srfi-170.html, part 1 through 3.3 File system temp-file-prefix John Cowan 14 Aug 2020 13:22 UTC
Re: Final review of johnwcowan/srfi-170/srfi-170.html, part 1 through 3.3 File system temp-file-prefix hga@xxxxxx 14 Aug 2020 14:01 UTC

Re: Clearing up confusion, and Windows errors as POSIX errno's hga@xxxxxx 15 Aug 2020 16:50 UTC

> From: Lassi Kortela <xxxxxx@lassi.io>
> Date: Friday, August 14, 2020 10:27 AM
>
> Hmm, how about this:
>
> (make-foreign-error
>   'set 'windows
>   'number 2
>   'name 'ERROR_FILE_NOT_FOUND
>   'message "File not found"
>   'errno-name 'ENOENT)  ; <---------

Errr, are you here implying plists without the list as the argument to
make-foreign-status and raise-foreign-error?  That's more than OK, at
first thought.

I would do it as something like:

(raise-foreign-error
  'set 'posix
  'subset 'windows
  'errno 2 ; I'm lying, but eh.
  'name 'ERROR_FILE_NOT_FOUND
  'message "File not found"
  'errno-name 'ENOENT) ; I'm lying, but eh.

In the above, we'd use 'errno-name in the 'posix 'set to not reserve
the very common and generic 'name for other uses.  From that
viewpoint, 'errno-number would also be very good, it's certainly all
but totally unambiguous, whereas our discussions have show 'errno can
be interpreted in a zillion ways.  So:

(raise-foreign-error
  'set 'posix
  'subset 'windows
  'errno-number 2 ; I'm lying, but eh.
  'name 'ERROR_FILE_NOT_FOUND
  'message "File not found"
  'errno-name 'ENOENT) ; I'm lying, but eh.

> The 'errno-name property could be a generic one for mapping the native
> errors from various systems into equivalent errnos, on a close-enough
> basis. For example, any kind of "file not found" error could be mapped
> to 'ENOENT.

Or just use it in all cases.  We want all 'posix 'sets to be regular,
and the 'subset 'windows key/value pair whispers "We're lying to you
for your own good."

> Using ('set 'errno 'name ENOENT 'number 2) is a bit deceptive when we
> know the error is from the Windows API and know the GetLastError() code.
> We should return the native Windows code instead. But if we add an extra
> 'errno-name that should give the best of both worlds.

Agreed to all points.

> Perhaps 'errno-equivalent, 'errno-equiv or a simple 'errno as Harold
> suggested would be a better name for the property. Users who care about
> portable code would be writing code like this:

To keep it portable and more clear, 'errno-name, so I modify what you did
below to:

> (define (read-symlink-if-exists path)
>   (guard (err ((and (foreign-status? err)
>                     (eq? 'ENOENT (foreign-status-ref err 'errno-name)))
>                #f))
>          (read-symlink path)))

Back to the real you:

> That doesn't look bad to me, especially given that Windows could be
> supported with the same code while preserving native WinAPI error
> information.

- Harold