all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Paul Eggert <eggert@cs.ucla.edu>
To: Alan Mackenzie <acm@muc.de>
Cc: Eli Zaretskii <eliz@gnu.org>,
	Stefan Monnier <monnier@iro.umontreal.ca>,
	emacs-devel@gnu.org
Subject: Re: Excessive use of `eassert`
Date: Tue, 23 Jan 2024 17:04:44 -0800	[thread overview]
Message-ID: <3bd8a47a-f082-43f3-a46e-1e35d99b0f01@cs.ucla.edu> (raw)
In-Reply-To: <Za-mM4EYJg9_AiRg@ACM>

On 1/23/24 03:42, Alan Mackenzie wrote:
> It's not about the debug build, but a normal build, where easserts don't
> play a role.
> 
> The scenario is when symbols_with_pos_enabled is false, and XSYMBOL is
> invalidly given a symbol with position as argument.  Before your
> patches, this would lead to an exception.  After your patches, this no
> longer happens.

I don't see a problem there. XSYMBOL can be called only on symbols, 
regardless of whether symbols-with-pos-enabled is true. When 
symbols-with-pos-enabled is false, XSYMBOL's argument therefore cannot 
be a symbol with position as these are symbols only when 
symbol-with-pos-enabled is true.

It sounds like you're thinking that, even in normal builds (i.e., 
without --enable-debugging), XSYMBOL's implementation should have some 
sort of debugging code that is not needed for correct behavior and that 
can slow down execution. I don't see why that needs to happen. In normal 
builds, XSYMBOL does not check that its argument is a symbol, and it has 
undefined behavior if buggy C code gives it a non-symbol. As I 
understand it, a symbol with position SP is not a symbol if 
symbols-with-pos-enabled is false. This means it's OK if XSYMBOL (SP) 
has undefined behavior when symbols-with-pos-enabled is false in a 
normal build.

Here's an example to try to make my meaning clearer. Suppose we define a 
buggy Lisp function in C as follows:

   DEFUN ("buggy-symbol-name", Fbuggy_symbol_name,
          Sbuggy_symbol_name, 1, 1, 0,
          doc: /* Return SYMBOL's name, a string.  */)
     (Lisp_Object symbol)
   {
     return XSYMBOL (symbol)->u.s.name;
   }

This C function has a bug: it doesn't check that its argument is a 
symbol before calling XSYMBOL. And because of the bug, this:

   (buggy-symbol-name (position-symbol nil 1))

has undefined behavior when Emacs is built without --enable-debugging. 
In the current implementation this undefined behavior causes 
buggy-symbol-name to return "nil", whereas it would be nicer in some 
sense if Emacs crashed and dumped core due to the bug in the C code.

However, symbols with positions aren't necessarily being treated 
differently from other Lisp objects here. For example, this:

   (buggy-symbol-name "abc")

also has undefined behavior, and on my platform this latter expression 
returns nil, also without dumping core. Although it would also be nicer 
in some sense if Emacs crashed and dumped core due to the bug in the C 
code, Emacs doesn't do that, for valid performance reasons.

For Emacs to reliably crash right away in situations like these, it 
needs to be built with --enable-debugging.



  reply	other threads:[~2024-01-24  1:04 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-18 22:35 Excessive use of `eassert` Stefan Monnier
2024-01-19  7:04 ` Eli Zaretskii
2024-01-19 13:01   ` Stefan Monnier
2024-01-19 15:02     ` Eli Zaretskii
2024-01-19 15:50       ` Stefan Monnier
2024-01-19 16:23         ` Eli Zaretskii
2024-01-19 17:44           ` Stefan Monnier
2024-01-19 19:42       ` Alan Mackenzie
2024-01-19 19:56         ` Eli Zaretskii
2024-01-21  1:41         ` Paul Eggert
2024-01-21  9:57           ` Eli Zaretskii
2024-01-21 20:35             ` Paul Eggert
2024-01-21 10:59           ` Alan Mackenzie
2024-01-22  5:19             ` Paul Eggert
2024-01-22 13:07               ` Stefan Monnier
2024-01-22 14:37               ` Alan Mackenzie
2024-01-23  7:51                 ` Paul Eggert
2024-01-23 11:42                   ` Alan Mackenzie
2024-01-24  1:04                     ` Paul Eggert [this message]
2024-01-24 15:09                       ` Alan Mackenzie
2024-01-26  8:06                         ` Paul Eggert
2024-01-21 15:54           ` Stefan Monnier
2024-01-22  4:12             ` Paul Eggert
2024-01-22 13:20               ` Stefan Monnier
2024-01-23  8:15                 ` Paul Eggert
2024-01-23 17:11                   ` Stefan Monnier
2024-01-24  7:45                     ` Paul Eggert
2024-01-23 18:16                   ` Eli Zaretskii
2024-01-23 19:50                     ` 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=3bd8a47a-f082-43f3-a46e-1e35d99b0f01@cs.ucla.edu \
    --to=eggert@cs.ucla.edu \
    --cc=acm@muc.de \
    --cc=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    --cc=monnier@iro.umontreal.ca \
    /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.