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. > Could this patch please be reviewed and/or applied? Thanks.