unofficial mirror of guile-devel@gnu.org 
 help / color / mirror / Atom feed
From: Mark H Weaver <mhw@netris.org>
To: ludo@gnu.org (Ludovic Courtès)
Cc: Andy Wingo <wingo@pobox.com>, guile-devel@gnu.org
Subject: Re: [PATCH] Add internal-only port structure; move iconv descriptors there
Date: Sun, 31 Mar 2013 11:23:23 -0400	[thread overview]
Message-ID: <87r4iv61as.fsf@tines.lan> (raw)
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")

Hi Ludovic,

ludo@gnu.org (Ludovic Courtès) writes:

> Mark H Weaver <mhw@netris.org> 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’t imagine how changing the *name* of a member could change
> something to the structure’s 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’d remove
> ‘_t’ 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



  reply	other threads:[~2013-03-31 15:23 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-02-24 11:39 always O_BINARY? Andy Wingo
2013-02-24 12:08 ` Neil Jerram
2013-02-24 16:55 ` Mike Gran
2013-02-24 21:17 ` Ludovic Courtès
2013-02-28  3:24   ` Adding new information to scm_t_port (was Re: always O_BINARY?) Mark H Weaver
2013-02-28  8:53     ` Andy Wingo
2013-02-28 11:04       ` Ludovic Courtès
2013-02-28 13:09         ` Andy Wingo
2013-03-01  9:03           ` Ludovic Courtès
2013-03-05 18:55       ` Mark H Weaver
2013-03-27 20:00         ` [PATCH] Add private port structure, and move iconv descriptors there Mark H Weaver
2013-03-27 20:28           ` Ludovic Courtès
2013-03-27 20:51           ` Andy Wingo
2013-03-27 21:11             ` Mark H Weaver
2013-03-31  7:52             ` [PATCH] Add internal-only port structure; " Mark H Weaver
2013-03-31 13:20               ` Ludovic Courtès
2013-03-31 15:23                 ` Mark H Weaver [this message]
2013-03-31 22:06                   ` Ludovic Courtès
2013-04-01 18:57               ` Andy Wingo
2013-04-01 20:03                 ` Mark H Weaver
2013-04-01 20:54                   ` Andy Wingo
2013-04-01 21:04                     ` Andy Wingo
2013-03-31 19:44             ` [PATCH] Add private port structure, and " Mark H Weaver
2013-03-31 22:08               ` Ludovic Courtès
2013-04-01 19:04               ` Andy Wingo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/guile/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87r4iv61as.fsf@tines.lan \
    --to=mhw@netris.org \
    --cc=guile-devel@gnu.org \
    --cc=ludo@gnu.org \
    --cc=wingo@pobox.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).