[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Bug when compiling elc code?
From: |
Hadron |
Subject: |
Re: Bug when compiling elc code? |
Date: |
Wed, 08 Aug 2007 19:21:30 +0200 |
Sven Joachim <svenjoac@gmx.de> writes:
> [Please keep this topic on-list. Thanks.]
Better not to copy on email then - I thought I had replied to the
group. Sorry, about that.
>
> Hadron <hadronquark@googlemail.com> writes:
>
>> The problem is that even if personal.elc exists in 600 mode, then a
>> recompile puts it back to 644. This is surely a bug?
>
> Maybe, but other compilers (gcc, for instant) behave similarly: they
> remove the target before they write to it. And Emacs has a good
> reason to do this, as can be seen from this comment in the
> byte-compile-file function in bytecomp.el:
As I said in private email, this is not the same thing. passwords etc
tend not to be hard coded into C/C++ files - they are in external
resource/config files which can be cleartext but are hidden by the linux file
permissions in many cases (or even gnupg encrypted).
At the very least I would think that the compile should maintain the
read/access modes of the original .el file.
Either that or something as happened to me might well happen to others
without them realising it. I can see no drawback to keeping the mode of
the elc file as the same as that of the source. Or?
>
> ,----
> | (when (file-exists-p target-file)
> | ;; Remove the target before writing it, so that any
> | ;; hard-links continue to point to the old file (this makes
> | ;; it possible for installed files to share disk space with
> | ;; the build tree, without causing problems when emacs-lisp
> | ;; files in the build tree are recompiled).
> | (delete-file target-file))
> | (write-region (point-min) (point-max) target-file))
> `----
>
> Regards,
> Sven
>
>
--
Message not available