Re: [PATCH] Add internal-only port structure; move iconv descriptors there

[Mark H Weaver]

Hi Andy,

Andy Wingo <address@hidden> writes:

> LGTM if these are addressed:
>
> On Sun 31 Mar 2013 09:52, Mark H Weaver <address@hidden> 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