unofficial mirror of help-gnu-emacs@gnu.org
 help / color / mirror / Atom feed
From: Hadron <hadronquark@googlemail.com>
To: help-gnu-emacs@gnu.org
Subject: Re: Bug when compiling elc code?
Date: Wed, 08 Aug 2007 19:21:30 +0200	[thread overview]
Message-ID: <26ejiej61x.fsf@googlemail.com> (raw)
In-Reply-To: mailman.4536.1186591345.32220.help-gnu-emacs@gnu.org

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

-- 

  parent reply	other threads:[~2007-08-08 17:21 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-08-08 10:29 Bug when compiling elc code? Hadron
2007-08-08 11:37 ` Johan Bockgård
2007-08-08 12:17 ` Sven Joachim
     [not found]   ` <d3abt22nwk.fsf@googlemail.com>
2007-08-08 16:45     ` Sven Joachim
     [not found]     ` <mailman.4536.1186591345.32220.help-gnu-emacs@gnu.org>
2007-08-08 17:21       ` Hadron [this message]
     [not found] ` <mailman.4528.1186577289.32220.help-gnu-emacs@gnu.org>
2007-08-08 13:18   ` Johan Bockgård
2007-08-08 14:59     ` Sven Joachim
     [not found]     ` <mailman.4534.1186585008.32220.help-gnu-emacs@gnu.org>
2007-08-08 16:09       ` weber
2007-08-08 16:57         ` Sven Joachim

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=26ejiej61x.fsf@googlemail.com \
    --to=hadronquark@googlemail.com \
    --cc=help-gnu-emacs@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).