bug-gnu-emacs
[Top][All Lists]
Advanced

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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]