Paul Eggert <
address@hidden> schrieb am Mi., 30. März 2016 um 03:35 Uhr:
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.
If emacs_value* were a real pointer, then the feature would come for free.
As Stefan mentioned, one can easily use Qnil etc. as sentinels.
These aren't sentinels because functions can return nil without existing non-locally.
> - 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 old approach relied only on standard C library functions and well-defined and well-known behavior. It didn't require knowledge about the internals of Lisp_Object.
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.
XCAR etc. certainly can't be avoided. We should try to reduce undefined behavior though, not add more.
If the main objection here is seeing bit operations like "<<" in
emacs-module.c,
It is not the main objection.
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.