Quoting Jonathan Wilkes jancsika@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...