Re: Excessive use of `eassert`

[Alan Mackenzie]

Hello, Paul.

On Tue, Jan 23, 2024 at 17:04:44 -0800, Paul Eggert wrote:
> 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.

That's humpty-dumpty logic.  Just because s-w-p-e is false is no
guarantee that XSYMBOL won't get a SWP as argument.

> 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.

No, I'm saying that an invalid bit pattern in XSYMBOL's logic should not
be treated as though it were valid.  No other invalid bit pattern allows
Emacs to continue blithely unaware.

And as for "can slow down execution", your measurement of 0.4%, if it's
not just background noise, is microscopic.  That would be less than a
second in a 4 minute bootstrap build.

> 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.

In normal builds, an invalid argument leads to a crash.  After your
patches, it only sometimes leads to a crash.  This is a loss of
functionality.

Why did you not discuss this change in functionality on the list
_before_ making it?

> 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.

The behaviour is not formally "undefined" and never has been.  It is not
formally anything (which is why we're arguing about it).  You've changed
the definition to "behaves as though symbols_with_pos_enabled were
true".  This breaks the consistency of the symbols with position
mechanism.

All for a barely measurable speed up.

Or should we just accept SWP everywhere, and abolish
symbols_with_pos_enabled?  That would at least preserve consistency,
though I don't think it would be a good thing to do.

[ .... ]

> 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.

That feels like a bug.

[ .... ]

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

That is impractical for most developers due to the vast slowdown (not
just 0.4%) it causes.

Again, please restore the functionality you've ripped out.

-- 
Alan Mackenzie (Nuremberg, Germany).