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


--
Ivica Ico Bukvic, D.M.A.
Associate Professor
Computer Music
ICAT Senior Fellow
DISIS, L2Ork
Virginia Tech
School of Performing Arts - 0141
Blacksburg, VA 24061
(540) 231-6139
i...@vt.edu
www.performingarts.vt.edu
disis.music.vt.edu
l2ork.music.vt.edu


_______________________________________________
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Reply via email to