Paul Eggert <
address@hidden> schrieb am Do., 19. Nov. 2015 um 16:55 Uhr:
The main thing I noticed (that was not already in your list or in my
upcoming changes) are some problems in memory allocation. The module
code calls malloc directly, instead of xmalloc, for reasons I don't
understand. This leads to problems, e.g., the memory is not properly
accounted for by the memory profiler. Why can't the new module code
invoke xmalloc? More generally, how should modules obtain memory in an
Emacs-friendly way?
The problem with xmalloc is that it can signal (i.e. call longjmp). Modules are generally not prepared for long jumps, so it's important that no longjmp escapes into module code. The easiest way to ensure this is to make code not call longjmp in the first place.
Some of the code in module.c does call longjmp; that is protected by appropriate calls to setjmp. We could do that with all code, but for cases like malloc it seemed simple enough to avoid the calls to longjmp altogether.
Maybe we should add a variant that behaves like xmalloc but is guaranteed to never call longjmp?
Also, the file name "emacs_module.h" doesn't use the usual Emacs style
rules; hyphen not underscore.
If a hyphen is preferred, feel free to rename.
But as you say, "module.h" would be better
anyway. I'll change it to "module.h" for now; if there's some reason it
needs an "emacs" prefix we can change it to "emacs-module.h" later.
Please don't use module.h; this header file is the only one that is intended for module authors to include, so it needs a globally unique name which should start with 'emacs'.
There are some other things I noticed which I'll try to summarize after
fixing the stuff that's easy to fix (missing copyright notices,
formatting, etc.).