From: Paul Eggert <eggert@cs.ucla.edu>
To: Philipp Stephani <p.stephani2@gmail.com>,
Daniel Colascione <dancol@dancol.org>,
emacs-devel@gnu.org, Stefan Monnier <monnier@iro.umontreal.ca>
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 [thread overview]
Message-ID: <56FB2D4E.5000609@cs.ucla.edu> (raw)
In-Reply-To: <CAArVCkS6tQzuH1SwFaB+f8jKZQN7Wmg39hoA-DuQunsK5tkdFA@mail.gmail.com>
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.
next prev parent reply other threads:[~2016-03-30 1:35 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20151130193446.22218.14685@vcs.savannah.gnu.org>
[not found] ` <E1a3UDm-0005my-HI@vcs.savannah.gnu.org>
2016-01-03 13:59 ` [Emacs-diffs] emacs-25 3eb93c0: Rely on conservative stack scanning to find "emacs_value"s Daniel Colascione
2016-01-03 15:45 ` Paul Eggert
2016-03-29 10:07 ` Philipp Stephani
2016-03-29 12:59 ` Stefan Monnier
2016-03-30 1:35 ` Paul Eggert [this message]
2016-03-30 18:26 ` Philipp Stephani
2016-03-30 18:28 ` Daniel Colascione
2016-03-30 18:42 ` Paul Eggert
2016-03-30 18:48 ` Daniel Colascione
2016-03-30 21:13 ` Stefan Monnier
2016-03-30 21:18 ` Daniel Colascione
2016-03-30 21:30 ` Stefan Monnier
2016-03-31 18:46 ` Philipp Stephani
2016-03-31 19:24 ` Daniel Colascione
2016-03-31 21:29 ` Stefan Monnier
2016-04-01 18:34 ` Daniel Colascione
2016-04-01 19:05 ` Stefan Monnier
2016-04-01 19:15 ` Daniel Colascione
2016-04-01 22:46 ` Stefan Monnier
2016-04-03 1:11 ` Daniel Colascione
2016-04-03 5:49 ` Stefan Monnier
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=56FB2D4E.5000609@cs.ucla.edu \
--to=eggert@cs.ucla.edu \
--cc=dancol@dancol.org \
--cc=emacs-devel@gnu.org \
--cc=monnier@iro.umontreal.ca \
--cc=p.stephani2@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.