Philipp Stephani
schrieb am Sa., 19. Dez. 2015 um
22:03 Uhr:
> Philipp Stephani schrieb am Sa., 28. Nov. 2015 um
> 11:58 Uhr:
>
>> Philipp Stephani schrieb am Fr., 27. Nov. 2015
>> um 20:19 Uhr:
>>
>>> Eli Zaretskii schrieb am Fr., 27. Nov. 2015 um 08:36 Uhr:
>>>
>>>> > Cc: emacs-devel@gnu.org
>>>> > From: Paul Eggert
>>>> > Date: Thu, 26 Nov 2015 13:29:49 -0800
>>>> >
>>>> > Eli Zaretskii wrote:
>>>> > > it would be a maintenance burden to have to
>>>> > > analyze upon each such change whether emacs-module.c needs some
>>>> > > augmentation.
>>>> >
>>>> > While that's true in general, I think some exceptions are OK. E.g.,
>>>> it's OK if
>>>> > emacs-module.c assumes that ASIZE is a simple access function or
>>>> macro that
>>>> > doesn't throw signals. If we actually changed ASIZE to throw
>>>> signals, there's a
>>>> > boatload of other code we'd need to change as well, and changing
>>>> emacs-module.c
>>>> > wouldn't add much more to the maintenance burden.
>>>>
>>>> So what are the rules here, exactly? I'd like to write them down in
>>>> the commentary to emacs-module.c, so that any future changes there
>>>> will have lower probability of breaking things.
>>>>
>>>> E.g., can make_number signal an error? What about make_float or
>>>> make_string? And what about accessors like XFLOAT_DATA or AREF?
>>>>
>>>>
>>> Are there any established rules? If not we should probably be
>>> conservative and assume that everything signals. If we figure out that
>>> this introduces an unacceptably high overhead in some situations we can
>>> reconsider later.
>>> I would propose three exceptions: free_global_ref, is_not_nil, eq.
>>> free_global_ref cannot fail in Daniel's design, and implementing it that
>>> way would be consistent with other resource deallocation functions such as
>>> free(3). is_not_nil and eq seem so fundamental that I cannot imagine a
>>> situation where they could ever fail. Documenting that these three cannot
>>> fail would free module authors from the need to check for errors after
>>> calling these functions.
>>>
>>
>> For now I've attached a patch to replace the initial setup of most
>> environment functions with a single macro.
>>
>
> Here's another patch that replaces some of the custom error handling with
> signals. The signals will be immediately caught by the prologue, but some
> complexity and duplication is removed.
>
Added another patch that documents some of the assumptions about non-local
exits. I've added them directly to lisp.h so that people changing these
definitions will hopefully notice.