[PD] Updated pd-extended
zmoelnig at iem.at
zmoelnig at iem.at
Sat Sep 27 17:49:15 CEST 2014
Quoting Jonathan Wilkes <jancsika at yahoo.com>:
> Now I'm even more confused. In the past you had written this to a
> query of mine:
[...]
>
> But now you say the opposite in response to DesireData's _symbol
> struct which adds a refcount and a symbol size member "n".
>
> How does the one break binary compatibility but the other does not?
i might have been mistaken.
the problem remains that as soon as we do add new members to a public
struct, somebody *might* use them.
and *this* is breaking binary compatibility.
e.g. if you external uses "(t_symbol*s)->n" you cannot run (nor
compile) it in Pd-vanilla.
if it does not, you still can.
if pd-l2ork adds the new members
<snip>
unsigned int refcount;
unsigned int length;
</snip>
and pd-extended adds the new members:
<snip>
unsigned int length;
unsigned int refcount;
</snip>
then any external that uses "(t_symbol*s)->n" will be doomed.
mfgasdr
IOhannes
PS: it would help if you posted a reference to the actual thread (e.g.
in the pd-list archives). i had trouble finding my contribution to the
thread you posted...
More information about the Pd-list
mailing list