Eli Zaretskii <address@hidden
> schrieb am Fr., 27. Nov. 2015 um 08:36 Uhr:
> Cc: address@hidden
> From: Paul Eggert <address@hidden>
> 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.