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.