On Mon 01 Apr 2013 22:54, Andy Wingo writes:
> Though we already violate them in innumerable ways in Guile, this is not
> one of those cases:
>
> struct foo { a a; b b; } *foo;
> foo = malloc (sizeof (*foo));
> a* a = &bar.a;
> b* b = &bar.b;
To be clear, I was suggesting to allocate som
On Mon 01 Apr 2013 22:03, Mark H Weaver writes:
>>>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_callo
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 his
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
Mark H Weaver skribis:
> l...@gnu.org (Ludovic Courtès) 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 o
Hi Ludovic,
l...@gnu.org (Ludovic Courtès) 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"
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
Here's a new start at adding an internal-only port structure to 2.0.
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 th
