[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#11585: 24.0.50; corrupted byte compiled files
From: |
Pierre Lorenzon |
Subject: |
bug#11585: 24.0.50; corrupted byte compiled files |
Date: |
Wed, 30 May 2012 17:28:47 +0200 (CEST) |
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.
>