Re: Bug when compiling elc code?

[Hadron]

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

--