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

From: Eli Zaretskii <[email-masked]>
Date: Mon, 12 May 2025 17:23:52 +0300

> From: Lynn Winebarger <[email-masked]>
> Date: Mon, 12 May 2025 10:05:36 -0400
> Cc: [email-masked], [email-masked], [email-masked]
> 
> 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.

No, the ABI hash is the evidence for the Emacs binary.  We need
evidence for the .eln file's code.

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

You've changed the subject: I was talking about the time stamp.

As for your proposal, I'm not sure it is better, let alone
significantly better.  Emacs currently looks for the .eln without
reading the .elc file, only because the .elc file was found.  You
suggest reading the .elc file, which will probably be slow on Windows
for the same reason computing the content hash is slow.  (We currently
don't open the .elc file on Windows because of this slowness, we just
ask the filesystem whether the file exists.)

So it is not clear to me that this complication (which will as a side
effect make the .elc files incompatible with previous Emacs versions)
is justified.  Someone will have to show a significant speedup to make
it worth considering.