From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Philipp Stephani
Eli Zaretskii <eliz@gnu.org> schrieb am Fr., 27. Nov. 2015 um 08:36=C2=A0Uhr:
=> Cc: emacs-devel@gnu.org
> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Thu, 26 Nov 2015 13:29:49 -0800
>
> Eli Zaretskii wrote:
> > it would be a maintenance burden to have to
> >=C2=A0 =C2=A0 =C2=A0 analyze upon each such change whether emacs-m= odule.c needs some
> >=C2=A0 =C2=A0 =C2=A0 augmentation.
>
> While that's true in general, I think some exceptions are OK.=C2= =A0 E.g., it's OK if
> emacs-module.c assumes that ASIZE is a simple access function or macro= that
> doesn't throw signals.=C2=A0 If we actually changed ASIZE to throw= signals, there's a
> boatload of other code we'd need to change as well, and changing e= macs-module.c
> wouldn't add much more to the maintenance burden.
So what are the rules here, exactly?=C2=A0 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?=C2=A0 What about make_float or
make_string?=C2=A0 And what about accessors like XFLOAT_DATA or AREF?
Are there any established rules? If not we should probabl= y be conservative and =C2=A0assume that everything signals. If we figure ou= t that this introduces an unacceptably high overhead in some situations we = can reconsider later.I would propose three exceptions: free_glob= al_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 deall= ocation functions such as free(3). is_not_nil and eq seem so fundamental th= at I cannot imagine a situation where they could ever fail. Documenting tha= t these three cannot fail would free module authors from the need to check = for errors after calling these functions.