From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Dynamic modules: MODULE_HANDLE_SIGNALS etc. Date: Wed, 25 Nov 2015 20:39:04 +0200 Message-ID: <83mvu1x6t3.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1448476788 28559 80.91.229.3 (25 Nov 2015 18:39:48 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 25 Nov 2015 18:39:48 +0000 (UTC) Cc: emacs-devel@gnu.org To: dancol@dancol.org, tzz@lifelogs.com, p.stephani2@gmail.com, aurelien.aptel+emacs@gmail.com Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Nov 25 19:39:37 2015 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1a1eyc-0003KX-Cg for ged-emacs-devel@m.gmane.org; Wed, 25 Nov 2015 19:39:34 +0100 Original-Received: from localhost ([::1]:47147 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a1eye-0001AI-1A for ged-emacs-devel@m.gmane.org; Wed, 25 Nov 2015 13:39:36 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:43511) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a1eyQ-00015G-1I for emacs-devel@gnu.org; Wed, 25 Nov 2015 13:39:22 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a1eyL-0004iD-Ul for emacs-devel@gnu.org; Wed, 25 Nov 2015 13:39:21 -0500 Original-Received: from mtaout25.012.net.il ([80.179.55.181]:37635) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a1eyL-0004hx-NB for emacs-devel@gnu.org; Wed, 25 Nov 2015 13:39:17 -0500 Original-Received: from conversion-daemon.mtaout25.012.net.il by mtaout25.012.net.il (HyperSendmail v2007.08) id <0NYD00400VJ0CV00@mtaout25.012.net.il> for emacs-devel@gnu.org; Wed, 25 Nov 2015 20:36:26 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([84.94.185.246]) by mtaout25.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NYD00IULVOQYK90@mtaout25.012.net.il>; Wed, 25 Nov 2015 20:36:26 +0200 (IST) X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 80.179.55.181 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:195240 Archived-At: 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?