Bugs item #1577739, was opened at 2006-10-15 20:42 Message generated for change (Comment added) made by fbar You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1577739...
Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: puredata Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Frank Barknecht (fbar) Assigned to: Miller Puckette (millerpuckette) Summary: Malformed data at end of patch is treated as sender
Initial Comment: When opening a patch file Pd doesn't check correctly if all messages are well-formed. Inserting a line at end of a patch file, that starts with a symbol and ends with a ";" will treat the leading symbol as a receive-target and will send the rest of the line to that receiver.
For example inserting:
pd dsp 1;
at the end of a patch will switch on audio, even when the patch is started with "pd -noloadbang".
While this message is harmless, other messages may do nasty things and open a security hole.
Attached is a patch that illustrates this behaviour, also see this pd-list message thread:
http://lists.puredata.info/pipermail/pd-list/2006-10/043161.html
----------------------------------------------------------------------
Comment By: Frank Barknecht (fbar)
Date: 2008-08-05 09:46
Message: Logged In: YES user_id=569446 Originator: YES
I didn't know about or think of this use case, which definitely is interesting.
Some more questions: You write "if objects forget about these messages it is rather broken objects ..." I thought, Pd itself forgets the data at the end, not certain objects in Pd or am I wrong?
Then: Currently it seems, only FTM uses the space at the end of a patch ("EOP"?) to store additional data. I didn't yet check how FTM does this, but what if other objects also start using the EOP-data? Could this lead to conflicts where one object overwrites data of another object? I think, with Pd's traditional way of storing data in #-lines, this generally cannot happen.
----------------------------------------------------------------------
Comment By: IOhannes m zmlnig (zmoelnig) Date: 2008-08-04 19:44
Message: Logged In: YES user_id=564396 Originator: NO
even if matju thinks you can use [loadbang] for these kind of things, he might be wrong here.
the sent messages are sent immediately (even before a hypothetic [initbang] message!), whereas the loadbang is delayed rather long. (as we all now)
as claude has pointed out, the "freer than max" talk should show (i hope) that you can really do cool things with this additional data, which you could not do with any other "elegant" method i know.
if objects forget about these messages it is rather broken objects than a bug in Pd. (e.g. the FTM-objects happily save (and recall) the data via this send-"hack")
----------------------------------------------------------------------
Comment By: ClaudiusMaximus (claudiusmaximus) Date: 2008-08-04 19:18
Message: Logged In: YES user_id=769033 Originator: NO
I think it is a feature too - if I recall correctly, the "Freer Than Max: Porting FTM to Pure-data" presentation at LAC showed that externals can save additional data to a Pd patch, using precisely this feature to re-access it on load.
----------------------------------------------------------------------
Comment By: Frank Barknecht (fbar) Date: 2008-08-04 19:01
Message: Logged In: YES user_id=569446 Originator: YES
But as a feature it is rather broken, because the data at the end of the file is deleted if you save the patch from Pd. And even the feature can be build in Pd itself with a loadbang'd semicolon-message box, as matju pointed out here: http://lists.puredata.info/pipermail/pd-list/2006-10/043171.html
----------------------------------------------------------------------
Comment By: IOhannes m zmlnig (zmoelnig) Date: 2008-08-04 18:45
Message: Logged In: YES user_id=564396 Originator: NO
i think this is a feature
----------------------------------------------------------------------
You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1577739...
-
SourceForge.net