|
From: | Paul Eggert |
Subject: | Re: [Emacs-diffs] emacs-25 3eb93c0: Rely on conservative stack scanning to find "emacs_value"s |
Date: | Tue, 29 Mar 2016 18:35:10 -0700 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.1 |
On 03/29/2016 03:07 AM, Philipp Stephani wrote:
- From a user's perspective, it removes NULL as a sentinel value to signal an error.
It's not clear that this feature is worth the hassle of supporting it. As Stefan mentioned, one can easily use Qnil etc. as sentinels.
- From a developer perspective, it adds low-level complexity, bit-twiddling, and possibly undefined behavior to a module that should only contain glue code between two interfaces.
The old approach was also complicated; its data structures were more complex and typically a bit slower, and it had more lines of code and it was typically more of a pain to debug at the C level. The new approach's use of undefined bit-twiddling isn't bad, given that even the old approach bit-twiddled with abandon by calling XCAR, XCDR and the like.
If the main objection here is seeing bit operations like "<<" in emacs-module.c, we could move uses of these operations from emacs-module.c to lisp.h so that emacs-module.c could be more abstract. Rearrange the deck chairs, so to speak.
[Prev in Thread] | Current Thread | [Next in Thread] |