Re: scratch/comp-static-data 5aa3db2f11: comp: Add support for compiling elisp constants into static data.

[Eli Zaretskii <eliz@gnu.org>]

> From: vibhavp@gmail.com
> Cc: akrl@sdf.org, luangruo@yahoo.com, emacs-devel@gnu.org
> Date: Sun, 20 Nov 2022 22:07:12 +0530
> 
> The follow elisp snipper is an example of code that when compiled under
> this branch, crashes Emacs:
> ;; -*- lexical-binding: t; -*-
> (defun fault-function ()
>   (let ((a [1 2 3]))
>     (aset a 0 5)
>     a))
> 
> (fault-function)

Then I think Richard is right, and we shouldn't do this.  It is OK to signal
an error in this case, but not crash the entire Emacs session.

> Therefore, `lisp_data_3' gets stored in .rodata (or .data.rel.ro),
> which causes the call to `aset' to trigger a SIGSEGV. This behaviour is
> documented by the Elisp reference manual, which states that self-
> evaluating forms are immutable, and changing then can read to
> crashes/undefined behaviour
> (https://www.gnu.org/software/emacs/manual/html_node/elisp/Self_002dEvaluating-Forms.html
> ).

The documentation says "don't do that!", but it's a far cry from an actual
crash.

Sorry, I'm against doing this in Emacs.

> The idea behind this patch is to replace the runtime initialization of
> lisp objects in the original bytecode constant vector with static
> variables, compiled into the eln itself. For now, it is able to do so
> for strings (without text properties), bare symbols in `lispsym',
> floats, vectors (and other psuedovectors in the future), and conses.
> Objects that require runtime initialization (for instance, interned
> symbols) are still created by calling their respective initialization
> functions, and are not able to be stored as consts.

I understand, but if the price is such crashes, it's a price I don't think
we want to pay.