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.