From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Mark H Weaver Newsgroups: gmane.lisp.guile.devel Subject: Re: [PATCH] Add internal-only port structure; move iconv descriptors there Date: Mon, 01 Apr 2013 16:03:20 -0400 Message-ID: <87vc8610jb.fsf@tines.lan> References: <87vc9ij5z0.fsf@pobox.com> <87fw0l2yyk.fsf@gnu.org> <877gltxgrg.fsf_-_@tines.lan> <87y5e8stst.fsf@pobox.com> <87d2vdekws.fsf@tines.lan> <87d2uk62a0.fsf_-_@tines.lan> <87a9poin2d.fsf@pobox.com> <87zjxk57l6.fsf_-_@tines.lan> <87fvzadqpv.fsf@pobox.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1364846633 25766 80.91.229.3 (1 Apr 2013 20:03:53 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 1 Apr 2013 20:03:53 +0000 (UTC) Cc: Ludovic =?utf-8?Q?Court=C3=A8s?= , guile-devel@gnu.org To: Andy Wingo Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Mon Apr 01 22:04:18 2013 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1UMkxl-0003mg-P6 for guile-devel@m.gmane.org; Mon, 01 Apr 2013 22:04:17 +0200 Original-Received: from localhost ([::1]:37211 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UMkxN-00068O-0o for guile-devel@m.gmane.org; Mon, 01 Apr 2013 16:03:53 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:39117) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UMkxJ-00067Q-N4 for guile-devel@gnu.org; Mon, 01 Apr 2013 16:03:50 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UMkxI-0005JD-4S for guile-devel@gnu.org; Mon, 01 Apr 2013 16:03:49 -0400 Original-Received: from world.peace.net ([96.39.62.75]:57350) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UMkxI-0005J8-09; Mon, 01 Apr 2013 16:03:48 -0400 Original-Received: from 74-94-165-125-newengland.hfc.comcastbusiness.net ([74.94.165.125] helo=tines.lan) by world.peace.net with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1UMkx9-0004Yo-M1; Mon, 01 Apr 2013 16:03:39 -0400 In-Reply-To: <87fvzadqpv.fsf@pobox.com> (Andy Wingo's message of "Mon, 01 Apr 2013 20:57:00 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 96.39.62.75 X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:16099 Archived-At: Hi Andy, Andy Wingo writes: > LGTM if these are addressed: > > On Sun 31 Mar 2013 09:52, Mark H Weaver writes: > >> +#define SCM_INTERNAL_PTAB_ENTRY(x) \ >> + ((scm_t_port_internal *) (SCM_PTAB_ENTRY(x)->input_cd)) >> + > > SCM_PORT_GET_INTERNAL(x) ? PTAB is a historical name (port table; there > is no more port table.) Good idea, will do! >> SCM z = scm_cons (SCM_EOL, SCM_EOL); >> - scm_t_port *entry = (scm_t_port *) scm_gc_calloc (sizeof (scm_t_port), "port"); >> + scm_t_port *entry = scm_gc_typed_calloc (scm_t_port); >> + scm_t_port_internal *pti = scm_gc_typed_calloc (scm_t_port_internal); >> const char *enc; > > How about allocating a struct { scm_t_port a; scm_t_port_internal b; } > and get the pointers from there? I was hoping to do something like this in master, but having thought about it some more, I don't see how to do this without running afoul of the strict aliasing rules. I confess that I don't yet fully understand the rules, but it sounds like we're not allowed to access that combined struct you propose above except via that a pointer to that combined struct. So says Marcus Brinkmann: http://thread.gmane.org/gmane.os.hurd.l4/1519 In other words, we'd need to modify SCM_PTAB_ENTRY to access it through that combined struct, which in turn means that we'd have to export the complete definition of 'scm_t_port_internal' to the user, and that would defeat our original goal. I suspect that Marcus is correct. Section 6.5, clause 7, of C11 states: An object shall have its stored value accessed only by an lvalue expression that has one of the following types: * a type compatible with the effective type of the object, * a qualified version of a type compatible with the effective type of the object, * a type that is the signed or unsigned type corresponding to the effective type of the object, * a type that is the signed or unsigned type corresponding to a qualified version of the effective type of the object, * an aggregate or union type that includes one of the aforementioned types among its members (including, recursively, a member of a subaggregate or contained union), or * a character type. Where an 'object' is defined as "region of data storage in the execution environment, the contents of which can represent values" (section 3.15). So entire structs are considered objects. As I interpret this, a 'scm_t_port' object can be accessed via your combined struct above, but not vice versa. Maybe I'm missing something, but I see nothing above that clearly permits your combined struct to be accessed via a bare 'scm_t_port *'. Remember that the purpose of all this is to prevent the compiler from having to constantly refetch things from memory every time anything is written to memory. Toward that end, it is crucial to minimize the number of legal aliases, and there's every reason to believe that compilers will become increasingly aggressive about this. Anyway, if it turns out that this is doable somehow, we can easily change it later, since all accesses to the internal structure are made via the 'SCM_PORT_GET_INTERNAL' macro. Thanks! Mark