Re: ANSIC_error & OS_error &c

[Sam S. <sd...@gn...>]

Hi Bruno,

On Tue, Aug 2, 2011 at 8:44 PM, Bruno Haible <br...@cl...> wrote:
>> ... for automated error recovery one has to parse
>> the error message to distinguish between, say, EPERM and ENOENT.
>> Thus I want to add a $CODE slot to OS-ERROR which would contain the
>> error code
>
> Good point, yes.
>
>> (symbolic, converted by check_errno_reverse in the syscalls
>> module).
>
> Hmm, since OS_error is used throughout stream.d, pathname.d, and others,
> I think this means to move the big DEFCHECKER which defines check_errno_reverse
> from a module to the core of clisp.

no, defchecker uses modprep.
the core is only used by the developers; they can live without that,
just on strerror.

>> However, once we start keeping the error code slot in the condition
>> object, there is no good reason for os-error to be a simple-error
>> because we can now do
>>     (define-condition os-error (error)
>>       (($code :initarg :code :reader os-error-code))
>>       (:report (lambda (c s)
>>                  (let ((code (os-error-code c)))
>>                    (format s "~S=~S: ~S" code (errno code) (strerror code))))))
>> where STRERROR returns the message for the code and ERRNO converts
>> between the symbolic and numeric codes.
>> Thus I will remove simple-os-error.
>
> I disagree. The point is to to have localized error messages. strerror is
> not guaranteed to provide a localization (and on most systems, it doesn't).
> That's why we have all these GETTEXT calls in errunix.d.

of course the return value of strerror/FormatMessage will go through gettext.

> I would say: Keep the error message, _and_ add the symbolic error code.

Since the literal strings will be gone from the clisp sources,
I see no difference between calling gettext(strerror(errno)) at
make-condition time
(as it is done now) vs at print-condition time (as I propose).

>> However, while on unix there is only one kind of error (OS-error, errno),
>> windows have two kinds: OS-error (GetLastError) and ANSIC-error (errno).
>> Thus I have 4 options for windows:
>>1- make os-error abstract and os-error-ansi & os-error-win32 inherit from it
>>2- make os-error mean ansi C errno (like on unix) and os-error-win32
>>   inherit from it
>>3- make os-error mean win32 GetLastError error and os-error-ansic inherit
>>   from it
>>4- make a single os-error class with an extra slot $ANSICP which will
>>   tell me whether the code is errno or GetLastError; alternatively,
>>   store GetLastError as a negative number.
>
> Good question. Option 3 is too Win32 centric IMO, I would drop that.

yep, I kept it for symmetry only.

> If GetLastError() values and errno values were unrelated concepts, option 1
> would be perfect.
>
> But GetLastError() values can be mapped to errno values. Such a mapping already
> occurs in MSVCRT.DLL, for functions like read() and write(). There are
> typically more than 1 GetLastError() values for a single errno value; therefore
> you can view GetLastError() as a "finer" classification of errors than errno
> values.

I am not sure what you mean here.
you cannot use errno with FormatMessage or GetLastError with strerror.
IIUC, any mapping between errno and GetLastError must be done by hand by us,
MS does not provide any API for that.
(there might be something in gnulib though).

> This mapping of errno values is also what will reduce the testing effort
> for programs. Code that does
>   (case (error-code e)
>     (ENOENT ...))
> can work on Win32 as well.

sure, as long as (type-of E) is ansi-c-error, not win32-error.

> The distinction between option 2 and option 4 is based on whether you consider
> Win32 API as important per se, or just an artefact of a weird platform. For me
> it's the latter.

agreed.

> I don't like to have Win32 API present in Linux builds of
> clisp. Therefore my preference is for option 2.

non sequitur.
option 4 with GetLastError values being negative (internally) actually
emphasizes
weirdness of windows quite nicely.
and if you prefer the extra ansicp slot, it will, of course, be
present only on windows.

-- 
Sam Steingold <http://sds.podval.org>