From: Pierre Lorenzon <devel@pollock-nageoire.net>
To: 11585@debbugs.gnu.org
Subject: bug#11585: 24.0.50; corrupted byte compiled files
Date: Wed, 30 May 2012 17:28:47 +0200 (CEST) [thread overview]
Message-ID: <20120530.172847.356956325.devel@pollock-nageoire.net> (raw)
In-Reply-To: <87sjeh7mna.fsf@gnu.org>
From: Chong Yidong <cyd@gnu.org>
Subject: Re: bug#11585: 24.0.50; corrupted byte compiled files
Date: Wed, 30 May 2012 22:45:45 +0800
> Pierre Lorenzon <devel@pollock-nageoire.net> writes:
>
>> It seems that a part of the .elc file is missing as if a part of the
>> character strream was discarded.
>
> This is certainly one of the most interesting bugs I've come across in
> quite some time. Congrats on finding it.
Well there should be two circumstances simultaneously : 1. a
long file name, 2. a compiled code containing utf-8
characters. 2 is probalby avoided by english speakers as well
as other language speakers who simply write code. But when
this code is automatically generated by auctex by a french
speaker whose LaTeX code contains non ascii characters it may
occur. Anyway that's probably why we discovered this bug so
late.
>
> The problem is that `byte-compile-fix-header' tries to insert a message
> within a fixed amount of space (in order to preserve file positions of
> the actual bytecode), so long file names embedded in the message will
> cause it to fail. Your proposed fix would not preserve file positions,
> but here is another way to fix it.
But why this need of fixing file position ? It seems to me
that header fix is the last operation in compising the byte
compiled code. After that file is saved and buffer is simply
discarded so position is lost.
>
> Stefan, I think this problem is serious enough, and the solution
> straightforward enough, that we ought to include it in emacs-24 even
> though it is not a regression. WDYT?
>
>
> === modified file 'lisp/emacs-lisp/bytecomp.el'
> *** lisp/emacs-lisp/bytecomp.el 2012-03-26 19:10:00 +0000
> --- lisp/emacs-lisp/bytecomp.el 2012-05-30 14:40:25 +0000
> ***************
> *** 1956,1966 ****
> ;; don't try to check the version number.
> " (< (aref emacs-version (1- (length emacs-version))) ?A)\n"
> (format " (string-lessp emacs-version \"%s\")\n" minimum-version)
> ! " (error \"`"
> ! ;; prin1-to-string is used to quote backslashes.
> ! (substring (prin1-to-string (file-name-nondirectory filename))
> ! 1 -1)
> ! (format "' was compiled for Emacs %s or later\"))\n\n"
> minimum-version))
> ;; Now compensate for any change in size, to make sure all
> ;; positions in the file remain valid.
> --- 1956,1965 ----
> ;; don't try to check the version number.
> " (< (aref emacs-version (1- (length emacs-version))) ?A)\n"
> (format " (string-lessp emacs-version \"%s\")\n" minimum-version)
> ! ;; Because the header must fit in a fixed width, we cannot
But why ? My solution without a fix header size produces
perfectly loadable .elc files. What is the good reason to
have this constrain of fix header size ?
Regards
Pierre
> ! ;; insert arbitrary-length file names:
> ! (format
> ! " (error \"Unable to load library compiled for Emacs %s or later\"))\n\n"
> minimum-version))
> ;; Now compensate for any change in size, to make sure all
> ;; positions in the file remain valid.
>
next prev parent reply other threads:[~2012-05-30 15:28 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-30 6:57 bug#11585: 24.0.50; corrupted byte compiled files Pierre Lorenzon
[not found] ` <handler.11585.B.133836288230357.ack@debbugs.gnu.org>
2012-05-30 8:05 ` bug#11585: Acknowledgement (24.0.50; corrupted byte compiled files) Pierre Lorenzon
2012-05-30 8:49 ` Pierre Lorenzon
2012-05-30 14:45 ` bug#11585: 24.0.50; corrupted byte compiled files Chong Yidong
2012-05-30 15:28 ` Pierre Lorenzon [this message]
2012-05-30 15:24 ` Stefan Monnier
2012-05-30 15:31 ` Pierre Lorenzon
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20120530.172847.356956325.devel@pollock-nageoire.net \
--to=devel@pollock-nageoire.net \
--cc=11585@debbugs.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.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.