From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Miles Bader Newsgroups: gmane.emacs.devel Subject: Re: Alignment of Lisp_Subr Date: Wed, 12 Nov 2003 18:30:13 -0500 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <20031112233013.GB27000@fencepost> References: NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1068680814 22034 80.91.224.253 (12 Nov 2003 23:46:54 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 12 Nov 2003 23:46:54 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Thu Nov 13 00:46:51 2003 Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1AK4hH-0000lY-00 for ; Thu, 13 Nov 2003 00:46:51 +0100 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1AK4hG-0006r4-00 for ; Thu, 13 Nov 2003 00:46:50 +0100 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.24) id 1AK5YM-000191-J0 for emacs-devel@quimby.gnus.org; Wed, 12 Nov 2003 19:41:42 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.24) id 1AK5Wg-0007g5-4i for emacs-devel@gnu.org; Wed, 12 Nov 2003 19:39:58 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.24) id 1AK5W6-0007B8-2i for emacs-devel@gnu.org; Wed, 12 Nov 2003 19:39:52 -0500 Original-Received: from [199.232.76.164] (helo=fencepost.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.24) id 1AK5Ve-0006wD-Ju for emacs-devel@gnu.org; Wed, 12 Nov 2003 19:38:54 -0500 Original-Received: from miles by fencepost.gnu.org with local (Exim 4.24) id 1AK4RB-0007uP-S4; Wed, 12 Nov 2003 18:30:13 -0500 Original-To: Stefan Monnier Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i Blat: Foop X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.2 Precedence: list List-Id: Emacs development discussions. List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:17785 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:17785 On Wed, Nov 12, 2003 at 11:22:33AM -0500, Stefan Monnier wrote: > - Structures of type Lisp_Subr are statically allocated and are not > guaranteed to be aligned on a multiple of 8. I currently solve this > by adding __attributes__ ((__aligned__ (8))), but this only works for GCC > AFAIK. The only alternative I can think of is to add a padding field > to Lisp_Subr and when its address is not a multiple of 8, memmove it > by a few bytes (I think `defsubr' is the only place where we refer > to these statically allocated Sfoo variables). > Any comment on which approach is preferable ? I think the compiler will force the structure to be aligned to the strictest alignment of any component, so if you stick an field with 8-byte-alignment in there _somewhere_, the compiler should do everything for you. It should even work to put the `forcing field' in as a member of a union with another field, and simply never use the forcing field. On many platforms, `double' could be used as the type of the forcing-field, but I'm not sure how universal this is. Given that subrs are not the most space critical object though, it seems simplest to just use __attributes__ when compiling with gcc (#ifdef __GNUC__), and add the padding field when compiling with another compiler. > - malloc does not guarantee on all systems that the returned value > will be a multiple of 8 (or does it?). It guarantees `most strict' alignment, which on many platforms is 8 bytes (because of doubles), and I think many malloc implementations are conservative and assume 8 bytes anyway. However I don't think you can assume this though; a quick google shows plenty of people complaining about exactly this issue (they expected 8-byte alignment, and got less; common culprits seem to be MS and SCO mallocs... :-) I guess in the common case where emacs uses its builtin malloc, or glibc's, you'll have #defines to tell you though... -Miles -- In New York, most people don't have cars, so if you want to kill a person, you have to take the subway to their house. And sometimes on the way, the train is delayed and you get impatient, so you have to kill someone on the subway. [George Carlin]