Dynamic modules: MODULE_HANDLE_SIGNALS etc.

[Eli Zaretskii]

These macros need more extensive documentation wrt when each one is
needed and why.

I tried to "reverse-engineer" that information from its current usage,
and my best hypothesis is that they should be used if a functions
calls some Emacs function that could potentially signal an error or
throw.  For example, module_make_function calls list4, module_funcall
calls Ffuncall, module_copy_string_contents calls ENCODE_UTF_8, etc.

Is that correct?

If it is, then I have a few questions:

  . Why don't some functions use any of these macros, although they do
    call Emacs functions?  Examples include module_make_integer (calls
    make_number), and module_make_user_ptr (calls make_user_ptr).

  . It seems like emacs-module.c assumes something about certain Emacs
    functions, and based on that decides not to use these macros even
    when calling those Emacs functions.  For example, module_vec_get
    calls ASIZE and AREF, but doesn't use the MODULE_HANDLE_* macros.
    Evidently, it assumes that neither ASIZE nor AREF will ever signal
    or throw.  But isn't that a fragile assumption?  The
    implementation of internal Emacs functions is subject to change
    without notice, and it would be a maintenance burden to have to
    analyze upon each such change whether emacs-module.c needs some
    augmentation.

  . How to decide whether to use MODULE_HANDLE_SIGNAL or
    MODULE_HANDLE_THROW (or both)?  Again, it looks like the current
    code simply assumes specific knowledge about certain Emacs
    functions, knowledge which again can become outdated a year or a
    month or a day from now.

So bottom line (again assuming my guesses above are correct), I'd
suggest to use these macros in all the emacs-module.c functions, and
in fact come up with a wrapper around calls to Emacs functions and
macros that will catch signals and throws, and make a point of calling
each such function/macro through that wrapper.

Comments?