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.