Frank Barknecht wrote:
The reason actually is quite simple: dumpOSC.c defines a maximum of atoms to hold in x->x_outat of being 50 as default, but later doesn't check at all, if this space is exceeded. Here's the relevant part of the struct declaration:
/* ----------------------------- dumpOSC ------------------------- */
#define MAXOUTAT 20
static t_class *dumpOSC_class;
typedef struct _dumpOSC { t_object x_obj; t_outlet *x_msgout; t_outlet *x_connectout; t_atom x_outat[MAXOUTAT]; int x_outatc; /* ... */ } t_dumpOSC;
Then later in the functions "dumpOSC_PrintTypeTaggedArgs" and "dumpOSC_PrintHeuristicallyTypeGuessedArgs" x->x_outat is happily filled with atoms as long as the incoming message list lasts, which of course is a recipe for desaster.
Now with my limited experience in C coding, I wonder, what's the best way to fix this.
I already wrapped all tries to append to x->x_outat in a big "if" clause which checks, if MAXOUTAT is reached. This works and keeps Pd from crashing. However somehow it doesn't feel right to just truncate the incoming message, even when posting a big warning message. OTOH I suppose, that declaring *x_outat with a fixed size was done for speed reasons. Having to allocate memory everytime a message comes in would be very slow.
But isn't the memory allocated only when the object is created and reused for each OSC message?
Maybe one could introduce an argument to dumpOSC which sets the maximum allowed message length (with a default of 50)?
From the OSC spec: " The underlying network that delivers an OSC packet is responsible for delivering both the contents and the size to the OSC application. An OSC packet can be naturally represented by a datagram by a network protocol such as UDP. In a stream-based protocol such as TCP, the stream should begin with an int32 giving the size of the first packet, followed by the contents of the first packet, followed by the size of the second packet, etc. " For UDP the data length field in the header is 16 bits and the header itself is 8 bytes, so up to 65528 bytes can be used for an OSC packet, and each element in the OSC packet is 4bytes long, the same size as a t_atom (not counting the path and typetags). So with MAXOUTAT 16382 there would be no problem and no need for a bounds check. 65528 bytes would be no bit memory hog for most people... But for TCP the message could be up to 4,294,967,295 bytes long :(
Martin