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: Sun, 31 Mar 2013 11:23:23 -0400 Message-ID: <87r4iv61as.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> <874nfr3duf.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1364743429 25587 80.91.229.3 (31 Mar 2013 15:23:49 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 31 Mar 2013 15:23:49 +0000 (UTC) Cc: Andy Wingo , guile-devel@gnu.org To: ludo@gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Sun Mar 31 17:24:16 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 1UMK7B-0001sB-JL for guile-devel@m.gmane.org; Sun, 31 Mar 2013 17:24:13 +0200 Original-Received: from localhost ([::1]:44634 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UMK6n-0005ap-1P for guile-devel@m.gmane.org; Sun, 31 Mar 2013 11:23:49 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:55459) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UMK6h-0005ak-Fw for guile-devel@gnu.org; Sun, 31 Mar 2013 11:23:45 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UMK6g-0008IL-55 for guile-devel@gnu.org; Sun, 31 Mar 2013 11:23:43 -0400 Original-Received: from world.peace.net ([96.39.62.75]:56077) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UMK6g-0008IC-10; Sun, 31 Mar 2013 11:23:42 -0400 Original-Received: from 209-6-91-212.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com ([209.6.91.212] helo=tines.lan) by world.peace.net with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1UMK6Y-0008NQ-Di; Sun, 31 Mar 2013 11:23:34 -0400 In-Reply-To: <874nfr3duf.fsf@gnu.org> ("Ludovic \=\?utf-8\?Q\?Court\=C3\=A8s\=22'\?\= \=\?utf-8\?Q\?s\?\= message of "Sun, 31 Mar 2013 15:20:40 +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:16068 Archived-At: Hi Ludovic, ludo@gnu.org (Ludovic Court=C3=A8s) writes: > Mark H Weaver skribis: > >> I've come to the conclusion that it is not safe to modify 'scm_t_port' >> in 2.0 at all; not even to change the member names. In brief, the >> reason has to do with the C11 standard definition of "compatible types", >> which ties into the strict aliasing rules. Section 6.2.7 of C11 spells >> out what it means for two structures declared in separate translation >> units to be compatible, and among other things their member names must >> be the same. > > I can=E2=80=99t imagine how changing the *name* of a member could change > something to the structure=E2=80=99s layout in practice. It doesn't change the structure's layout. However, it could cause link-time optimization to break our code. Basically, when linking together objects built with the old scm_t_port and the new scm_t_port, it's feasible that the compiler could compare the two structures by tag name, member names, etc, to determine if they are "compatible types" according to section 6.2.7. If they are not compatible types, then the linker is allowed to assume that pointers to these two distinct types cannot alias each other, and make optimizations appropriately. Of course this is a simplification of the detailed rules (and TBH I haven't yet taken the time to fully understand the rules myself), but from reading C11, I can see a potential for real problems in practice. >> +#define scm_gc_typed_calloc(t) ((t *) scm_gc_calloc (sizeof (t), #t)) > > Not really convinced by this, but hey. Ideally, this would need to go > in the manual too. Maybe talk to Andy about it? It was his suggestion. >> +typedef struct scm_t_port_internal >> +{ >> + /* input/output iconv conversion descriptors */ >> + void *input_cd; >> + void *output_cd; >> +} scm_t_port_internal; > > Please define the struct tag and typedef separately. Also, I=E2=80=99d r= emove > =E2=80=98_t=E2=80=99 from the struct tag, as discussed before. Okay. I was just following the conventions used in current Guile code, e.g. in ports.h, but I'll change it as you suggest. Thanks, Mark