GNU bug report logs - #59334
29.0.50; loading native-compiled init file sets user-init-file to .eln

Previous Next

Package: emacs;

Reported by: Juanma Barranquero <lekktu <at> gmail.com>

Date: Thu, 17 Nov 2022 09:30:02 UTC

Severity: normal

Fixed in version 29.0.50

Done: Juanma Barranquero <lekktu <at> gmail.com>

Bug is archived. No further changes may be made.

Full log


Message #44 received at 59334 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Juanma Barranquero <lekktu <at> gmail.com>
Cc: 59334 <at> debbugs.gnu.org, akrl <at> sdf.org
Subject: Re: bug#59334: 29.0.50; loading native-compiled init file sets
 user-init-file to .eln
Date: Fri, 18 Nov 2022 10:46:03 +0200
> From: Juanma Barranquero <lekktu <at> gmail.com>
> Date: Fri, 18 Nov 2022 08:45:03 +0100
> Cc: akrl <at> sdf.org, 59334 <at> debbugs.gnu.org
> 
> > I think the call to gethash should only be done if the file has the
> > .eln extension, otherwise you might have false positives.
> 
> Do you mean the hash comp-eln-to-el-h could have keys that match something that doesn't end in .eln? Or
> that someone could've an init file with extension .eln and matching one of the keys? Both seem extremely
> unlikely, but ok.

I thought about a possibility that the session loaded a .eln file, but
then the user or some Lisp explicitly loaded the .el file by hand.
I'm not sure in this case the hash table is updated.  Andrea, am I
right?




This bug report was last modified 2 years and 244 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.