[PD-dev] Whose fault is this crash? (nan and inf)

[katja]

On Tue, Sep 10, 2013 at 2:01 PM, Kjetil Matheussen
<k.s.matheussen at gmail.com> wrote:


>> Since most processors don't flush denormals and non-numbers to zero by
>> default, Pd classes have to deal with it in some selective way. If all
>> math objects (signal objects in particular) would flush those
>> generally undesired numbers to zero, that would make Pd slower. The
>> compromise is to flush problematic values wherever they cause a
>> serious problem, like recycling NaN's. In your [vd~] example the NaN
>> seems to result in an illegal pointer value. The same issue might
>> happen in other table reading objects with index inlets ([tabread],
>> [tabread4~], [cyclone/poke~]). Did you try that?
>>
>
> Thank you! That's what I wanted to know.
> I'll provide a more thought-through patch for vd~, and perhaps tabread4~
> and poke~ as well.
>
> The trouble with vd~ was a real world example (provided by a user) that
> made radium (with now has pd embedded) crash. He couldn't continue working
> on his song, since pd patches are saved inside radium song files, and radium
> crashed as soon as he tried to load the song.
>

Oops, that is a nasty case. I was just about to say: it is an open
question to what extent Pd must be idiot-proof. After all, Pd can be
considered a computer language, a patch can be considered a program,
and the programmer has some responsibility too. Why should one send
NaN as an index value or delay time to some object? Well, maybe
because Pd is often used for wild experiments, like the example case
illustrates. Pd should not crash on bugs in a patch I guess.

Katja