Hi list,Take the following shaky premise:Pd-L2ork is binary compatible with Pd-Vanilla.
- Can someone build a simple external with default widget behavior that violates this premise by crashing Pd-Vanilla/Pd-l2ork?
- Can someone build a simple external with custom widget behavior that violets this premise by crashing Pd-Vanilla/Pd-l2ork?
Background info: Pd-l2ork has an extra member at the _end_ of the t_widgetbehavior struct. This member is used to do accelerated displacing of a selection of objects in Pd. struct _widgetbehavior is defined in g_canvas.h. -Jonathan
On Mon, Jul 27, 2015 at 12:08 PM, Jonathan Wilkes via Pd-list pd-list@lists.iem.at wrote:
Background info: Pd-l2ork has an extra member at the _end_ of the t_widgetbehavior struct. This member is used to do accelerated displacing of a selection of objects in Pd.
This type of modification isn't meant to be binary compatible in both directions. Your Pd-Vanilla externals with the Vanilla t_widgetbehavior struct will not work in Pd-l2ork, because the struct is smaller.
When Pd-l2ork tries to access those elements off the end of the t_widgetbehavior struct, it should seg fault.
Thanks, Charles.
What if the Vanilla external has CLASS_DEFAULT widgetbehavior? Then Pd assigns c->c_wb to text_widgetbehavior.Since text_widgetbehavior is a hard-coded widgetbehavior it is guaranteed to have the number of members expected bythe code in g_editor.c. Is this right?
-Jonathan
On Monday, July 27, 2015 1:28 PM, Charles Z Henry <czhenry@gmail.com> wrote:
On Mon, Jul 27, 2015 at 12:08 PM, Jonathan Wilkes via Pd-list pd-list@lists.iem.at wrote:
Background info: Pd-l2ork has an extra member at the _end_ of the t_widgetbehavior struct. This member is used to do accelerated displacing of a selection of objects in Pd.
This type of modification isn't meant to be binary compatible in both directions. Your Pd-Vanilla externals with the Vanilla t_widgetbehavior struct will not work in Pd-l2ork, because the struct is smaller.
When Pd-l2ork tries to access those elements off the end of the t_widgetbehavior struct, it should seg fault.
On 07/27/2015 01:28 PM, Charles Z Henry wrote:
On Mon, Jul 27, 2015 at 12:08 PM, Jonathan Wilkes via Pd-list pd-list@lists.iem.at wrote:
Background info: Pd-l2ork has an extra member at the _end_ of the t_widgetbehavior struct. This member is used to do accelerated displacing of a selection of objects in Pd.
This type of modification isn't meant to be binary compatible in both directions. Your Pd-Vanilla externals with the Vanilla t_widgetbehavior struct will not work in Pd-l2ork, because the struct is smaller.
When Pd-l2ork tries to access those elements off the end of the t_widgetbehavior struct, it should seg fault.
Since pd-l2ork is compiled with a different widgetbehavior and assigns all new objects by default a null value to additional widgetbehaviors, unless 3rd-party external explicitly somehow overrides widgetbehavior, this will not crash. The only situation where I think it may crash is if a 3rd party external tries to copy an object and tries to allocate memory for a specific widgetbehavior size, which seems questionable since externals should not have to worry about widgetbehavior size and IIRC this part is instantiated inside core pd routines.
Best,
Ico
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-
Charles Z Henry -
Ivica Ico Bukvic -
Jonathan Wilkes