all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
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.
> 





  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.