[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