Subject: bug#78340: [PATCH] New option for comp *.eln file name by the file timestamp of *.el

From: Lynn Winebarger <[email-masked]>
Date: Mon, 12 May 2025 10:05:36 -0400

On Mon, May 12, 2025 at 9:53 AM Eli Zaretskii <[email-masked]> wrote:
>
> > From: Lynn Winebarger <[email-masked]>
> > Date: Mon, 12 May 2025 09:42:06 -0400
> > Cc: [email-masked], [email-masked], [email-masked]
> >
> > I don't really follow the logic on why the content hash of the current
> > source is required to keep emacs from *crashing*, as opposed to just
> > being inconsistent with the current source.
>
> How else can you make sure the native code is safe to run?  E.g., what
> if the code calls primitives that don't exist in Emacs, or their
> signature is different?

That's what the ABI hash does.  The content hash doesn't prove
anything about that.

>
> > That state of affairs has always been considered acceptable for byte
> > compiled libraries.
>
> It was a requirement to prevent crashing a session due to loading
> incompatible native code, because loading byte-code doesn't crash.
>
> > So, instead of checking file times, why not just put the content hash
> > in the .elc, and if loading the elc would be acceptable (determined by
> > file times), then use the value from the elc file (stored in the
> > comment block at the start so the Fread procedure is not required).
>
> I don't see how the time stamp of the .elc file is more reliable than
> of the .el file.

If the byte-compiler notes in its output (by this comment tag) "this
elc was compiled from a source file with content hash X", then why
would X not be satisfactory for determining if the .eln was generated
from valid elisp code?  If someone can write to the elc file, they can
probably write to the .eln file as well and change the embedded
content hash to whatever they want if that's the concern.

Lynn