From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Ken Raeburn Newsgroups: gmane.emacs.devel Subject: Re: PURESIZE increased (again) Date: Thu, 27 Apr 2006 18:29:31 -0400 Message-ID: References: <87lku5u6tx.fsf@pacem.orebokech.com> <200604272212.k3RMCe4C001158@jane.dms.auburn.edu> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1146177049 24440 80.91.229.2 (27 Apr 2006 22:30:49 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 27 Apr 2006 22:30:49 +0000 (UTC) Cc: eliz@gnu.org, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Apr 28 00:30:47 2006 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1FZF0X-0008PQ-8g for ged-emacs-devel@m.gmane.org; Fri, 28 Apr 2006 00:30:45 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FZF0W-00070k-PM for ged-emacs-devel@m.gmane.org; Thu, 27 Apr 2006 18:30:44 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1FZF0L-00070X-Nv for emacs-devel@gnu.org; Thu, 27 Apr 2006 18:30:33 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1FZF0K-00070K-3R for emacs-devel@gnu.org; Thu, 27 Apr 2006 18:30:33 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FZF0J-00070H-UD for emacs-devel@gnu.org; Thu, 27 Apr 2006 18:30:31 -0400 Original-Received: from [204.127.192.81] (helo=rwcrmhc11.comcast.net) by monty-python.gnu.org with esmtp (Exim 4.52) id 1FZF2S-0003x7-45; Thu, 27 Apr 2006 18:32:44 -0400 Original-Received: from raeburn.org (c-65-96-168-237.hsd1.ma.comcast.net[65.96.168.237]) by comcast.net (rwcrmhc11) with ESMTP id <20060427222936m11005f1o4e>; Thu, 27 Apr 2006 22:29:36 +0000 Original-Received: from [18.18.1.160] (NOME-KING.MIT.EDU [18.18.1.160]) by raeburn.org (8.12.11/8.12.11) with ESMTP id k3RMTZlQ001123; Thu, 27 Apr 2006 18:29:35 -0400 (EDT) In-Reply-To: <200604272212.k3RMCe4C001158@jane.dms.auburn.edu> Original-To: Luc Teirlinck X-Mailer: Apple Mail (2.749.3) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:53524 Archived-At: On Apr 27, 2006, at 18:12, Luc Teirlinck wrote: >> From my previous message: > > Of course, using different compilers or different C Libraries, > _including_ different version numbers for the same compiler or > library > will not have any effect on the .el file, but it can definitely > have > an effect on the .elc files > > On second thought, this seems less immediately obvious, from a purely > "logical" point of view. But apparently, from the empirical evidence, > differences in compiler, library or OS do seem to matter much more > compiled Lisp files. Probably, the alignment issues are more complex > for them. From what I've seen of the Lisp structures and allocation code, I'd be very surprised if this were true. You *may* get different compilers imposing different alignment/padding constraints for structures or unions, but such cases should be very rare and arguably reported as bugs (it'll lead to interoperability problems if they're used on the same system), and I doubt any of the types Emacs Lisp uses get any significant padding. And I don't think there are many data types allocated in loading a .elc file that are not used when loading a .el file. Ken