#555 never send NULL selectors to objects

[IOhannes m zmölnig]

when an object receives bang/float/symbol/pointer messages without having a bang/float/symbol/pointer method defined, it will use the list method instead (if the object has set one).

however, this list method is called with a selector set to 0 (NULL).

if the object passes on the exact incoming message to its outlet (keeping the NULL selector intact), this will lead to a crash, in most cases:
-if the downstream object has an anything method and accesses the selector name without checking for NULL first (e.g. [print] will simply crash because it tries to print the non-existing selector) OR
- if the downstream object has no anything method, the dispatcher will crash when trying to display the no method for ... error

since this means that NULL-selectors are forbidden within Pd, Pd shouldn't emit them intentionally.

attached are two patches:
- 0001-never-send-NULL-selectors-to-objects.patch makes sure that the dispatcher does not generate messages with a NULL-selector.
- 0002-gracefully-handle-messages-with-NIL-selector.patch makes sure that at least the dispatcher does not crash if it encounters a method with a NULL-selector (as generated by some random object).

the first patch is more important.

[IOhannes m zmölnig]

forgot to attach the files...

[Miller Puckette]

I'm not sure this is a real problem - _anything and _list methods simply aren't guaranteed
anything about the "s" argument - it shouldn't ever be dereferenced.

[IOhannes m zmölnig]

On 2015-09-10 01:01, Miller Puckette wrote:

I'm not sure this is a real problem - _anything and _list methods simply aren't guaranteed
anything about the "s" argument - it shouldn't ever be dereferenced.

oha.

1. why do we have the "s" argument in the first place?
2. shouldn't there be a huge blinking sign in m_pd.h that warns against it's use?
3. i see that the "s" argument (to the _anything method) is used in
   Pd-code, though hardly ever dereferenced (notable exception being
   print_anything()) - am i just nitpicking?

in any case:
the problem really was found from a crasher-bug triggered by zexy's
[relay] object. (and object similar to [route] but without stripping the
selector).
[relay] doesn't do any dereferencing of the "s" argument.
however, it passes the "s" argument on to outlet_anything(), which will
then crash Pd's message dispatcher.

so to revert the question: is the Pd-dispatcher 'guaranteed anything
about the "s" argument' in the outlet_list() and outlet_anything() methods?

if not, then the 0002-gracefully-handle-messages-with-NIL-selector.patch
(attached to the ticket) will fix it (however, it doesn't fix the buggy
[print] object that dereferences the "s" argument in its _anything() method.