[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Excessive use of `eassert`
From: |
Eli Zaretskii |
Subject: |
Re: Excessive use of `eassert` |
Date: |
Tue, 23 Jan 2024 20:16:35 +0200 |
> Date: Tue, 23 Jan 2024 00:15:03 -0800
> Cc: Alan Mackenzie <acm@muc.de>, Eli Zaretskii <eliz@gnu.org>,
> emacs-devel@gnu.org
> From: Paul Eggert <eggert@cs.ucla.edu>
>
> On 2024-01-22 05:20, Stefan Monnier wrote:
> > Compared to the patch I proposed this has the downside that it
> > duplicates the logic between `lisp_h_builtin_lisp_symbol` and
> > `make_lisp_symbol`
> Yes, when --enable-checking is used the tradeoff is: would we rather
> omit all runtime checking in make_lisp_symbol (the patch you proposed),
> or omit it only for builtin symbols (the patch I installed)?
>
> For builtin symbols like Qnil and Qt the runtime checking is not all
> that useful - if these symbols' data items are improperly aligned Emacs
> will crash early anyway. For non-builtin symbols the runtime checking is
> arguably useful, to catch (presumably rare) alignment bugs in the memory
> allocator.
>
> If you'd rather have the simpler solution that doesn't catch alignment
> bugs in non-builtin symbols, I could prepare a patch along those lines.
> Any such alignment bugs are pretty unlikely, after all.
I think we should settle for builtin symbols, since the other kind is
unlikely to cause any significant slowdown, and the extra level of
testing is valuable in debug builds.
I hope Stefan will agree.
- Re: Excessive use of `eassert`, (continued)
- Re: Excessive use of `eassert`, Stefan Monnier, 2024/01/21
- Re: Excessive use of `eassert`, Paul Eggert, 2024/01/21
- Re: Excessive use of `eassert`, Stefan Monnier, 2024/01/22
- Re: Excessive use of `eassert`, Paul Eggert, 2024/01/23
- Re: Excessive use of `eassert`, Stefan Monnier, 2024/01/23
- Re: Excessive use of `eassert`, Paul Eggert, 2024/01/24
- Re: Excessive use of `eassert`,
Eli Zaretskii <=
- Re: Excessive use of `eassert`, Stefan Monnier, 2024/01/23