Quoting Jonathan Wilkes <jancs...@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...
_______________________________________________
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
