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.