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: immediate strings #2 Date: Tue, 29 Nov 2011 10:48:17 -0500 Message-ID: <046388F1-7414-4B68-A870-20ADC9FB5C8C@raeburn.org> References: <4ED35057.8010103@yandex.ru> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Trace: dough.gmane.org 1322581717 30468 80.91.229.12 (29 Nov 2011 15:48:37 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 29 Nov 2011 15:48:37 +0000 (UTC) Cc: Emacs Dev To: Andreas Schwab Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Nov 29 16:48:33 2011 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1RVPv4-0001lT-3K for ged-emacs-devel@m.gmane.org; Tue, 29 Nov 2011 16:48:30 +0100 Original-Received: from localhost ([::1]:50883 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RVPv3-0007CH-KE for ged-emacs-devel@m.gmane.org; Tue, 29 Nov 2011 10:48:29 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:42492) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RVPv0-0007C7-Tx for emacs-devel@gnu.org; Tue, 29 Nov 2011 10:48:27 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RVPuv-0003ab-8T for emacs-devel@gnu.org; Tue, 29 Nov 2011 10:48:26 -0500 Original-Received: from mail-vw0-f41.google.com ([209.85.212.41]:56821) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RVPuv-0003aQ-61 for emacs-devel@gnu.org; Tue, 29 Nov 2011 10:48:21 -0500 Original-Received: by vbbfn1 with SMTP id fn1so6645814vbb.0 for ; Tue, 29 Nov 2011 07:48:20 -0800 (PST) Original-Received: by 10.52.36.41 with SMTP id n9mr48649161vdj.41.1322581700287; Tue, 29 Nov 2011 07:48:20 -0800 (PST) Original-Received: from squish.raeburn.org (c-66-31-202-94.hsd1.ma.comcast.net. [66.31.202.94]) by mx.google.com with ESMTPS id a2sm48812532vdj.3.2011.11.29.07.48.18 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 29 Nov 2011 07:48:18 -0800 (PST) In-Reply-To: X-Mailer: Apple Mail (2.1084) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Received-From: 209.85.212.41 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:146348 Archived-At: On Nov 29, 2011, at 03:44, Andreas Schwab wrote: > Ken Raeburn writes: >=20 >> Well, I think Stefan's technically right... the "as-if" rule lets the >> compiler get away with a lot, if it can analyze enough of the program >> to figure out that it wouldn't make a difference to the semantics >=20 > Only if the address is never taken, or sizeof is never applied. If the compiler really wants to play some games in the name of space = optimization, it could pack the type as densely as possible (rearrange = or eliminate fields, limit integer or pointer fields to the number of = bits that will actually get used, etc) for actual storage, and still = print sizes and offsets consistent with the official alignment rules for = the platform, if it can keep the two cases straight. (Allocating the = actually-used smaller size instead of the larger "normal" size would = still be consistent as long as the difference isn't visible by certain = criteria; I'm pretty sure process size under "ps" isn't one of those = criteria.) It'd be a lot of effort and probably not worthwhile, but not = outside of the rules. Ken